Environment and filesystem
Every harness session runs in an isolated microVM with its own filesystem and shell. This page covers configuring the execution environment (default or custom container), running commands directly on the VM, setting environment variables, and mounting persistent filesystems.
For development, use the Agent Inspector to invoke a deployed Harness from a local UI, or open an interactive Harness shell. Neither path runs the Harness environment locally.
Run commands on the environment
Not everything needs to go through the agent loop. InvokeAgentRuntimeCommand gives you direct shell access to the harness microVM: deterministic command execution with no model reasoning, no token cost, no ambiguity.
Use it to:
-
Run deterministic pre-invocation or post-invocation scripts.
-
Prepare the environment before an invocation: clone a repo, install dependencies, copy input files.
-
Act on what the agent produced: run tests, commit and push, extract build artifacts.
-
Inspect the VM during development:
ls,cat,env,python --versionwithout a round trip through the model.
Example
See InvokeAgentRuntimeCommand API for details.
Note
Commands run as root (uid 0) within the microVM. This is analogous to root on your own EC2 instance - the IAM permission is the access gate, not the in-VM privilege level. If your Dockerfile includes a USER directive, it applies to the agent process only (the container’s main entrypoint). InvokeAgentRuntimeCommand runs at a higher privilege level for operational purposes, similar to how docker exec defaults to root even when the container runs as a non-root user. See Execute shell commands in AgentCore Runtime sessions for full details on security, error handling, and best practices.
Custom environment (container images)
The base environment includes Python and bash, enough for most tasks. When you need more, package your source code, dependencies, runtimes, and tools into a container image, push it to ECR, and reference it on the harness. Your agent runs in that exact environment. Pair custom images with InvokeAgentRuntimeCommand for session-specific setup that varies per invocation.
Container images must be built for the linux/arm64 platform.
Include the following programs in your image:
-
Include
/bin/bash. The harness uses it for the shell tool, commands, and interactive terminals. -
Include
/bin/shandsleep. The harness uses them to keep the container running. -
Include
base64,cat,dirname,env,ls,mkdir, andrm. The file tools use them to read and write files. -
Include
tarwhen you configure Git, Amazon S3, or AWS skills. The harness uses it to copy these skills into the container.
When you configure Git, Amazon S3, or AWS skills, give the container user write access to /tmp. The harness copies these skills into /tmp before the agent starts.
Most general-purpose base images include these programs, but some minimal images don’t. For example, amazonlinux:2023 and amazonlinux:2 don’t include tar. Alpine and BusyBox images don’t include /bin/bash. To install tar on Amazon Linux, add RUN dnf install -y tar to your Dockerfile.
If you omit tar or write access to /tmp, invocations that use fetched skills fail. This applies to Git, Amazon S3, and AWS skills. The error is Unable to copy configured skills to the customer container. Add the missing program or permission to resolve the error. You don’t need tar for path skills because the harness reads them in place.
For more information about skill sources, see Skills.
The harness overrides your container’s ENTRYPOINT and CMD to keep it running as an environment. Your installed software, filesystem, and environment variables are available to the agent; your container’s startup command is not executed. If you need a background process (such as a dev server), start it via InvokeAgentRuntimeCommand after the session begins.
Example
Environment variables
Set environment variables that are passed to the runtime container. Environment variables are available to the agent and any custom container running in the session.
Example
Filesystem
The harness mounts persistent storage at paths you specify. Files written to these mounts survive session termination and are visible to later invocations.
A harness supports three filesystem types:
-
Session storage - service-managed, per-session storage that persists across stop/resume cycles for the same
runtimeSessionId. No VPC required. -
Amazon EFS access point - bring-your-own EFS file system, shared across sessions and agents. VPC required.
-
Amazon S3 Files access point - bring-your-own S3 Files file system that syncs bidirectionally with an S3 bucket. VPC required.
For prerequisites (VPC networking, IAM permissions, security groups), type comparison, limits, and lifecycle behavior, see File system configurations for AgentCore Runtime. The same requirements apply to harnesses.
Session storage
Files written to the mount path persist across stop/resume cycles when you invoke with the same runtimeSessionId.
Example
Amazon EFS access point
Attach an EFS access point ARN at a mount path under /mnt. Data persists in your account and can be shared with other harnesses or agent runtimes that mount the same access point.
Example
Amazon S3 Files access point
Attach an S3 Files access point ARN at a mount path under /mnt. Files at the mount path sync bidirectionally with the backing S3 bucket.
Example
Important
UpdateHarness replaces the entire filesystemConfigurations list. To add a new mount to a harness that already has filesystems configured, call GetHarness first, then send the full desired list (existing entries plus the new one) in UpdateHarness.
Learn more: File system configurations for AgentCore Runtime.
Related topics
-
Skills - attach skills from Git, S3, or AWS Skills
-
Memory - persist conversations across sessions
-
Tools - connect tools to your harness
-
Security and access controls - execution role policies and VPC configuration