Claude Code Remote on AWS Bedrock AgentCore: Close the Laptop, the Agent Keeps Working

On a Friday afternoon, you hand Claude Code a hard bug. Forty minutes later the tests still have not passed — and closing your laptop would kill the agent mid-task. That is the limit of a locally running agent: your machine is the dispatcher, the executor, and the credential store, with no shared queue and no central control across the team. Bedrock AgentCore solves exactly that: Claude Code runs remotely, one dedicated microVM per task inside your own AWS account, and when it finishes it opens a pull request for a human to review. This article follows the AWS blog post of 6 November 2026 and the sample repo aws-samples/sample-remote-coding-agent.

What Is Remote Claude Code on Bedrock AgentCore?

Every task becomes one AgentCore runtime session — a dedicated microVM — in your AWS account, with every model call through Amazon Bedrock. The agent clones the repo, writes code, runs verification commands, then pushes the agent/<taskId> branch and opens a pull request; it never merges. The difference is where state lives: locally in your terminal — close the laptop and it is gone; remotely in DynamoDB and SQS on AWS. No AWS key or GitHub token sits in your local shell either: the token is issued by AgentCore Identity, lasts 8 hours, and refreshes itself.

It is not a hosted SaaS — you deploy and operate the whole stack yourself; not a CI replacement; and not an autonomous agent — it stops after at most 3 retries and leaves a draft pull request. Best for teams already on AWS with a trusted repo that has setup and test ready and clearly scoped tasks: small features, bug fixes, writing tests. Skip it for untrusted repos, open-ended tasks with no definition of done, teams without a separate AWS account, or budgets that cannot accept an idle bill.

Architecture and How It Works

Submit work through the Claude Code sample-rca plugin or the web console (CloudFront + Cognito): a Lambda screens the prompt with Bedrock Guardrails, pushes it into an SQS queue, and a dispatcher Lambda starts one AgentCore runtime session. Inside the microVM, the agent clones the repo, checks AgentCore Memory for earlier lessons, plans with Claude Opus, writes code with Claude Sonnet, runs the repo’s setup and test commands, then reviews with Opus — up to 3 attempts — before pushing the agent/<taskId> branch and opening a pull request (draft if verification has not passed).

Architecture Diagram

flowchart TD
    A["User<br/>Claude Code plugin sample-rca<br/>or Web Console (CloudFront + Cognito)"] --> B["API Gateway + Lambda<br/>Receives the task"]
    B --> C["Bedrock Guardrails<br/>Screens only the task prompt"]
    C -->|Blocked prompt: PromptBlockedByGuardrail| X["Task rejected"]
    C --> D["DynamoDB: task state<br/>SQS: queue"]
    D --> E["Dispatcher Lambda"]
    E --> F["AgentCore Runtime microVM<br/>One microVM per task<br/>Memory sanitized when the session ends"]
    F --> G["AgentCore Memory<br/>Lessons across sessions"]
    F --> H["Claude Opus: planning + review"]
    F --> I["Claude Sonnet: writing code"]
    F --> J["Repo setup / test commands"]
    H -->|Up to 3 retries| I
    I --> J
    J --> H
    F --> K["GitHub App via AgentCore Identity<br/>8-hour token, auto-refresh"]
    K --> L["Branch agent/&lt;taskId&gt; + Pull Request<br/>Draft if verification has not passed"]
    L --> M["Human reviews and merges by hand<br/>Agent never merges"]
    F -.->|"All model calls only via Amazon Bedrock<br/>DNS Firewall blocks api.anthropic.com"| N["Amazon Bedrock"]
    F -.->|"Private VPC, outbound HTTPS<br/>via NAT gateway"| O["GitHub / Package registry"]

Key Components

The microVM is the isolation layer: one task, one microVM, memory sanitized when the session ends. AgentCore Memory is the only component that carries lessons across sessions — and the surface needing the most careful governance. Bedrock is the only route to a model: the runtime IAM role may invoke only Anthropic models, and Guardrails blocks jailbreaks, prompt injection, malware requests, and secrets in the prompt. DynamoDB, SQS, and the dispatcher Lambda form the asynchronous queue; the GitHub App (Contents and Pull requests) with AgentCore Identity issues short-lived tokens bounded by the app’s install list; the private VPC has VPC endpoints, a NAT gateway for outbound HTTPS only, and a Route 53 DNS Firewall blocking the model vendor’s domains.

Verified Limits

Regions supporting AgentCore runtime V2: us-east-1, us-east-2, us-west-2, ap-northeast-1, eu-west-1 (the AWS post uses us-west-2) — ap-southeast-1 (Singapore) is not included.

The repo must declare its own commands — a Makefile with setup and test targets, or a package.json with scripts.setup and scripts.test — and an empty repo must be scaffolded first with scripts/scaffold.sh or /sample-rca:scaffold, or the task fails when opening the pull request.

Deployment Guide

Prerequisites: a separate AWS account (ideally dedicated, separated from production); AWS CLI; Docker running; Python 3.11+; uv; Node.js 22.12+ per the AWS blog (README: Node ≥ 20; I recommend 22.12+); plus a GitHub account able to create a GitHub App and a trusted repo with setup and test.

Before deploying, set the profile and region you will use:

export AWS_PROFILE=<your-profile>
export AWS_REGION=us-west-2

Deploying outside us-east-1 still needs CDK bootstrap there; make preflight prints the command. The standard commands, per the official AWS documentation:

git clone https://github.com/aws-samples/sample-remote-coding-agent
cd sample-remote-coding-agent
make setup
make preflight
make deploy EMAIL=you@example.com

Deployment takes about 15–25 minutes, mostly building the ~1.3 GB ARM64 image locally — AWS’s figures; I have not run it myself. make preflight must pass first: preflight is read-only, while deploy starts billing immediately.

After deploying, connect GitHub in the console: confirm the prepared GitHub App description, then choose Install on GitHub with Only select repositories, installing only the registered repo. Registering takes another 8–12 minutes to reach READY; a task submitted before then returns 409 ConfigurationNotReady — install and authorize are two separate steps, both required.

Running Your First Task

Install the plugin, then restart Claude Code to load the MCP tools. Leave the configuration fields empty (RCA_API_URL, RCA_REGION, RCA_STACK_NAME) for automatic discovery — filling them in by hand can point at the wrong deployment:

/plugin marketplace add aws-samples/sample-remote-coding-agent
/plugin install sample-rca@sample-remote-coding-agent

After restarting, dispatch a task from a local clone of the registered repo:

/sample-rca:remote <task description>
/sample-rca:remote status

The web console pushes tasks into the same SQS queue: sign in via Cognito, type the task on the board, then Start run. A task moves through Backlog → Planning → Coding → Verifying → Done; Reviewing and Submitting sit inside Verifying. Done is not proof of success — only SUCCEEDED means verification ran and the review came back green. The final milestone is the agent/<taskId> branch with its pull request; if a task gets stuck, check the CloudWatch logs of the dispatcher and the runtime. Start with a small bug fix that already has tests.

Technical Assessment

Strengths

The isolation is real: one task per microVM, memory wiped when the session ends; model calls only via Bedrock inside your own account; no AWS credential inside the container; an 8-hour GitHub token; the agent does not merge. SQS and DynamoDB separate submitting from executing, so the whole team can submit without anyone’s machine staying on.

Weaknesses

Idle cost is the biggest drawback: the NAT gateway, endpoints, WAF, Cognito, DNS Firewall, images, and logs keep billing when no task is running. The default 200 USD/month budget only sends an email warning — it does not stop spending — and the sample repo publishes no official cost estimate. The sample is also very young: MIT-0 licensed, created 2026-09-01, last push 2026-11-05, only 2 stars and 0 forks — its credibility comes from being an official AWS sample, so its APIs or commands may change later. The 3-retry limit means open-ended tasks easily stop halfway, and the lack of a Singapore region is a practical downside for teams in Vietnam.

Security: 6 Control Layers and 1 Blind Spot

Six control layers: model calls only via Bedrock; isolated microVMs sanitized after each session; an 8-hour GitHub token; Guardrails screening the prompt; a private VPC with endpoints and DNS Firewall; least-privilege IAM — the runtime may only invoke Anthropic models and only read/write its own repo’s task records and memory. The blind spot: Guardrails screens only the task prompt, not repo files or command output — per AWS, screening every model call would re-evaluate the entire context and flag Claude Code’s own system prompt. So the real trust boundary sits in the repo content and the lessons in Memory, not in the prompt: a malicious instruction in a repo file or issue goes straight into context, and because Memory is not sanitized like the microVM, a bad lesson survives every later session.

The README states it directly: the GitHub App’s installation list is the blast radius — a token issued to one repo’s container can write to every repo where the app is installed. That is how GitHub Apps work, and the trade-off versus fine-grained per-repo tokens. Install the app only on repos registered to run the agent, use a GitHub account that owns nothing you would regret losing, and enable branch protection on the default branch before registering. Bedrock’s data claims — no training on customer data, SOC/ISO/FedRAMP Moderate, HIPAA eligible, Mantle zero operator access, zero data retention — are AWS vendor claims, not independently verified; zero data retention is a per-region opt-in that must be enabled and the model confirmed to support it, and the default global. inference profile may serve outside the deployment region, so pin a regional profile if data must stay in one geography. Cleanup: deregister repos first (1–3 minutes each), disconnect GitHub, destroy the stack, then delete the GitHub App — leftover DynamoDB tables, the Cognito pool, the access-log bucket, images, and log groups keep billing if not deleted by hand.

Comparison With Alternatives in the Same Scope

Running locally costs almost nothing, but your machine is the hostage and credentials sit in your shell. Local worktrees (Worktrunk, Orca) are cheap and fast but still local, with no shared queue. CC Switch solves model cost, not remote execution. Self-hosting on your own server means you handle isolation and credentials yourself. A hosted service is fastest to set up, but code and data leave your AWS account. AgentCore wins on isolation, short-lived credentials, and asynchronous execution inside your own AWS account; it loses on idle cost, setup complexity, and limited regions. See also CC Switch and Claude Code’s cross-session memory.

Real-World Use Cases

For an IT team on AWS, the best fit is handing over bug fixes and small features with tests, reviewing PRs centrally, keeping a dedicated AWS account for the agent separate from production, and using Memory so the agent learns repo conventions — or handing it a pre-written spec (see Spec Kit) and reviewing the PR against it. For DevOps/SRE, the value is dispatching a long task to run in the background and receiving a PR to review later; for a homelab or an individual who rarely uses AWS, local execution plus worktrees is cheaper and simpler.

Troubleshooting Common Issues

Repo not READY yet (409 ConfigurationNotReady): wait for READY, then submit again. Empty repo not scaffolded: the task fails at the end when opening the pull request — scaffold with scripts/scaffold.sh or /sample-rca:scaffold before registering. Missing setup or test: the PR opens as a draft — add both commands, then register again. Blocked prompt (PromptBlockedByGuardrail): rewrite the task, and keep secrets out of the prompt. Node: the README says Node ≥ 20, so Node 20 still passes setup and preflight — but the AWS blog requires 22.12+, so use 22.12+. Docker not running: deploy fails at the image-build step — start the Docker daemon, then run make deploy again. Unsupported region: error at preflight or deploy — switch to one of the five verified regions. GitHub App not installed on the repo: the agent cannot clone or push — check the app’s install list, then authorize again in the console; install and authorize are two separate steps. Rollback: there is no “undo” — close the pull request, delete the agent/<taskId> branch, deregister the repo if needed, and remove the bad lesson from Memory.

Conclusion

Remote Claude Code trades setup effort and idle cost for isolation, short-lived credentials, and asynchronous execution inside your own AWS account — worth it for teams already on AWS, not for everyone. Next step: try it on a secondary trusted repo with a small bug fix that has tests; measure deploy time, repo registration time, and the first week’s bill before bringing in your main repo.

Lessons Learned

1. You can close the laptop because state lives in DynamoDB and SQS, not in a local terminal — but you must watch the queue through CloudWatch.
2. The strongest security does not sit in the screened prompt, but in a trusted repo and clean Memory.
3. The 8-hour token and single-use microVM reduce credential-leak risk, but Memory survives every session — a bad lesson in Memory outlives them all.
4. Idle cost is a real cost: the 200 USD budget only warns, it does not cap; cleanup requires manually deleting resources left behind after the stack.
5. The 3-retry maximum is a design limit — tasks need a clear definition of done, expressed through the repo’s test command.

Verification Scope

Checked 2026-11-09 against the AWS ML Blog of 6/11/2026 and the repo aws-samples/sample-remote-coding-agent (MIT-0, 2 stars, push 2026-11-05): architecture, task flow, Guardrails, VPC, GitHub token, deploy commands, deploy and repo-registration times, idle cost, cleanup order. The DNS Firewall default is a denylist; AWS recommends a Network Firewall allowlist for production; the 200 USD budget is alert-only, not a cap. The figures of 15–25 minutes to deploy, 8–12 minutes to register a repo, an image of about 1.3 GB, and at most 3 retries are AWS configuration figures, not benchmarks. Not verified: I did not deploy the sample, measure real time or cost, or pin the Opus/Sonnet model versions.

References

• AWS Machine Learning Blog — Extend Claude Code to remote sessions on Amazon Bedrock AgentCore with security controls (6/11/2026)
• GitHub — aws-samples/sample-remote-coding-agent (README: Quick start, Architecture, Costs and cleanup, Troubleshooting)
• GitHub — README: Limitations
• GitHub — README: Security
• AWS — Amazon Bedrock AgentCore
• AWS — Amazon Bedrock Guardrails