Execute shell commands in AgentCore Runtime sessions
The InvokeAgentRuntimeCommand operation lets you execute shell commands directly
inside a running AgentCore Runtime session and stream the output back over HTTP/2. Commands run
in the same container, filesystem, and environment as your agent - the same session used by
InvokeAgentRuntime. This enables workflows where your application uses the
agent for reasoning tasks and commands for deterministic operations like running tests, git
operations, or environment setup.
To call InvokeAgentRuntimeCommand, you need
bedrock-agentcore:InvokeAgentRuntimeCommand permissions.
When to use InvokeAgentRuntimeCommand
| Use InvokeAgentRuntimeCommand | Use InvokeAgentRuntime |
|---|---|
The operation has a known command (npm test, git push) |
The operation requires reasoning ("analyze this code and fix the bug") |
| You want deterministic execution - same command, same result | You want the LLM to decide what to do |
| You need streaming output from a long-running process | You need the agent to use tools in a loop |
| The operation is a validation gate in your workflow | The operation is the creative or analytical work |
| You're bootstrapping the environment before the agent starts | You're asking the agent to work on a task |
How it works
InvokeAgentRuntimeCommand runs a shell command inside the container of
an active AgentCore Runtime session and streams the output back.
Same agent, same session
InvokeAgentRuntimeCommand operates on the same agent runtime and
session as InvokeAgentRuntime. You don't create separate resources.
The agent you deployed with CreateAgentRuntime accepts both agent
invocations and command execution on any active session.
Note
The AgentCore Runtime microVM does not include developer tools like git,
npm, or language runtimes by default. Any tools your commands
depend on must be included in your container image (via your Dockerfile) or
installed dynamically at runtime.
The response is a stream of three event types:
| Event | When | Contains |
|---|---|---|
contentStart |
First chunk | Confirms the command started |
contentDelta |
During execution | stdout and/or stderr output |
contentStop |
Last chunk | exitCode and status
(COMPLETED or TIMED_OUT) |
Output streams in real time. You see results as they run, not after they finish.
Prerequisites
-
bedrock-agentcore:InvokeAgentRuntimeCommandIAM permission -
A valid AgentCore Runtime endpoint ARN
Note
Agents created after March 17, 2026 support command execution automatically. If you deployed your agent before this date, you must redeploy it to update the agent runtime.
Execute a command
Coding agent workflow example
A common pattern is to use InvokeAgentRuntime for reasoning and
InvokeAgentRuntimeCommand for deterministic operations in the same
session.
Example End-to-end coding agent workflow
import boto3 import json client = boto3.client('bedrock-agentcore', region_name='us-west-2') AGENT_ARN = 'arn:aws:bedrock-agentcore:us-west-2:account-id:runtime/my-agent' SESSION_ID = 'session-id-at-least-33-characters-long' def run_command(command, timeout=60): """Helper to run a command and return the exit code.""" response = client.invoke_agent_runtime_command( agentRuntimeArn=AGENT_ARN, runtimeSessionId=SESSION_ID, contentType='application/json', accept='application/vnd.amazon.eventstream', body={'command': command, 'timeout': timeout} ) for event in response.get('stream', []): if 'chunk' in event and 'contentStop' in event['chunk']: return event['chunk']['contentStop'].get('exitCode') return None # Step 1: Invoke the agent to analyze and write a fix response = client.invoke_agent_runtime( agentRuntimeArn=AGENT_ARN, runtimeSessionId=SESSION_ID, payload=json.dumps({"prompt": "Read JIRA-1234 and implement the fix in /workspace"}).encode() ) # Process agent response... # Step 2: Run tests deterministically exit_code = run_command('/bin/bash -c "cd /workspace && npm test"', timeout=300) # Step 3: If tests pass, commit and push if exit_code == 0: run_command('/bin/bash -c "cd /workspace && git checkout -b fix/JIRA-1234"') run_command('/bin/bash -c "cd /workspace && git add -A && git commit -m \'Fix JIRA-1234\'"') run_command('/bin/bash -c "cd /workspace && git push origin fix/JIRA-1234"')
The agent writes the code. The platform runs the commands. Each does what it's best at.
Common use cases
- Running test suites
-
After the agent writes code, run the project's test suite as a command. The streaming response lets you detect failures early and feed specific error output back to the agent for iteration.
/bin/bash -c "cd /workspace && npm test 2>&1" - Git operations
-
Branching, committing, and pushing are deterministic operations. Run them as commands after the agent completes its work, keeping version control logic out of the LLM.
/bin/bash -c "cd /workspace && git add -A && git commit -m 'Fix issue'" - Dependency installation
-
Bootstrap the environment before invoking the agent -clone repos, install packages, set up build tooling. This preparation runs faster and more reliably as direct commands.
/bin/bash -c "pip install -r requirements.txt" - Build and compile
-
Compile steps and asset generation -anything with a known command that should run exactly as specified.
/bin/bash -c "cd /workspace && cargo build --release" - Linting and validation
-
Run code quality checks as a validation gate after the agent writes code, before committing.
/bin/bash -c "cd /workspace && npx eslint src/ --format json" - Environment inspection
-
Check runtime state, installed packages, available tools -useful for debugging agent failures.
/bin/bash -c "python --version && node --version && git --version" - Data operations
-
Fetch datasets, upload results, run data transformations -network and compute operations that run faster as direct commands.
/bin/bash -c "aws s3 cp s3://my-bucket/data.csv /workspace/"
Key design choices
- One-shot, non-interactive execution
-
Each command spawns a new bash process, runs to completion (or timeout), and returns. There is no persistent shell session between commands. This matches how agent frameworks use command execution -craft a command, run it, read the output, decide what to do next.
- Streaming response over HTTP/2
-
Output arrives as it's produced, not buffered until completion. A
npm testthat takes two minutes streams results in real time. Your application can detect a failure in the first few seconds and cancel early rather than waiting for the full run. - Container isolation
-
Commands execute inside the same container as your agent code. They see the same filesystem, environment variables, and installed packages. A file the agent wrote at
/workspace/fix.pyis immediately visible to a command runningcat /workspace/fix.py. - Non-blocking to the runtime
-
Command execution doesn't block agent invocations. You can invoke the agent and run commands concurrently on the same session. The platform handles the concurrency.
- Stateless between commands
-
Each command starts fresh -no shell history, no environment variable changes from previous commands carry over. If you need state, encode it in the command itself:
cd /workspace && export NODE_ENV=test && npm test.
Security considerations
Important
Under the AWS shared responsibility model, you are responsible for the security of the commands you execute in your AgentCore Runtime sessions. AWS provides the secure infrastructure and isolation at the microVM level. You are responsible for the commands you run, the data you process, and the access controls you configure.
The security boundary for command execution is the microVM. Each AgentCore Runtime session runs in an isolated microVM with its own kernel, memory, and filesystem. Commands you execute cannot access other customers' workloads or escape the VM boundary. However, within your VM, commands have full access to the container filesystem and any credentials or secrets you have configured.
Auditing with CloudWatch Logs
AgentCore Runtime sends the request ID and the input command to your agent's Amazon CloudWatch Logs log group. You can use these logs to monitor command activity and maintain an audit trail of what commands were executed in your sessions. The command execution output (stdout and stderr) is streamed back to your application and is not logged by the service.
Auditing with CloudTrail
AWS CloudTrail records InvokeAgentRuntimeCommand API calls in your
account. Each record includes metadata such as the caller identity, timestamp,
source IP address, and response status. CloudTrail does not log the request or response
payload. Use CloudTrail to audit who executed commands and when, then correlate with
CloudWatch Logs logs using the request ID to see what command was executed.
For sensitive workloads, consider implementing additional controls such as:
-
Using IAM policies to restrict which principals can call
InvokeAgentRuntimeCommand -
Configuring VPC endpoints to keep traffic within your network
-
Setting up CloudWatch Logs metric filters and alarms to detect unexpected command patterns
-
Reviewing CloudTrail logs regularly for unauthorized access attempts
Error handling
When using the InvokeAgentRuntimeCommand operation, you might encounter
the following errors:
- ValidationException
-
Occurs when the request parameters are invalid. Check that your agent ARN, session ID, and command are correctly formatted. The command must be between 1 byte and 64 KB, the timeout must be between 1 and 3600 seconds, and the session ID must be at least 33 characters.
- ResourceNotFoundException
-
Occurs when the specified agent runtime or session cannot be found. Verify that the agent ARN is correct and that the session is active.
- AccessDeniedException
-
Occurs when you don't have the necessary permissions. Ensure that your IAM policy includes the
bedrock-agentcore:InvokeAgentRuntimeCommandpermission. - ThrottlingException
-
Occurs when you exceed the request rate limit of 25 TPS. Implement exponential backoff and retry logic in your application.
A command that completes with a non-zero exit code is not an API error. Check the
exitCode in the contentStop event to determine if the
command itself succeeded. A status of TIMED_OUT indicates the
command exceeded the specified timeout.
Best practices
Follow these best practices when using the InvokeAgentRuntimeCommand
operation:
-
Use
InvokeAgentRuntimeCommandfor deterministic operations (tests, git, builds) andInvokeAgentRuntimefor reasoning tasks. Don't route deterministic operations through the LLM. -
Include any developer tools your commands depend on (such as
git,npm, or language runtimes) in your container image via your Dockerfile. -
Always check the
exitCodein thecontentStopevent to determine if the command succeeded. -
Set appropriate timeouts. A test suite might need 5 minutes, while a
git pushmight only need 30 seconds. -
Process streaming output incrementally to detect failures early. You can cancel a long-running command rather than waiting for it to complete.
-
Encode state in the command itself using
&&chaining (for example,cd /workspace && export NODE_ENV=test && npm test), since each command starts a fresh bash process. -
Use UUIDs for session IDs to meet the 33-character minimum requirement (for example,
12345678-1234-1234-1234-123456789012).