feat(agentcore): AWS Bedrock AgentCore Code Interpreter adapter - #19
Draft
miyaontherelay wants to merge 2 commits into
Draft
feat(agentcore): AWS Bedrock AgentCore Code Interpreter adapter#19miyaontherelay wants to merge 2 commits into
miyaontherelay wants to merge 2 commits into
Conversation
…adapter Implements a SandboxRuntime/WorkflowRuntime adapter for AWS Bedrock AgentCore's Code Interpreter, following the SDK-isolation, capability- reconciliation, and provenance discipline established by the Vercel and Modal adapters. Network mode defaults to VPC, never SANDBOX: public research disclosed in March 2026 (BeyondTrust Phantom Labs, corroborated by Unit 42 and the Cloud Security Alliance) showed AgentCore's SANDBOX network mode still permits outbound DNS A/AAAA queries despite blocking general internet traffic, enough to build a full covert C2 and data-exfiltration channel out of a "sandboxed" code interpreter. AWS's own mitigation is VPC mode plus a Route 53 Resolver DNS Firewall, not a SANDBOX-mode fix, so this adapter's config type makes VPC the only mode reachable without an explicit, named opt-in; choosing SANDBOX logs a warning citing the hazard every time. Lifecycle (stop/start) is omitted entirely, structurally false: a session's status is READY | TERMINATED only, with StopCodeInterpreterSession a terminal transition and no resume path -- the same shape modal-adapter-0821 documents for Sandbox.terminate(), adopted here for the same reason. No AWS credentials are configured in this build environment, so this ships with mocked/contract tests only (29 across runtime.test.ts/bench.test.ts). The live n=1/n=7 benchmark -- including the idle-billing measurement that is the load-bearing economics question for this adapter -- is blocked on credential provisioning; see docs/agentcore.md#credential-status for the exact IAM policy and role requirements. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H6cB7qLYbvnHjRZXbA4HUH Session-Id: 0f216d95-8216-426e-8ff9-90e28744f278
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
… adoption npm/pnpm were hanging in the earlier build environment (root cause: a symlinked ~/.npmrc pointing into a Dropbox-synced path that this sandbox can't reliably read). Worked around it with NPM_CONFIG_USERCONFIG=/dev/null, ran a real `npm install`, and that surfaced three real bugs a hand-written type shim couldn't catch: - InvokeCodeInterpreterCommand's `name` is the closed `ToolName` enum, not a plain string; cast at the one call site that constructs the vendor command, keeping the structural AgentCoreInvokeParams.name as `string` for test-fake ergonomics. - CodeInterpreterResult.isError is `boolean | undefined` in the real SDK, not required `boolean`. - InvokeCodeInterpreter's stream is a discriminated union (a `result` member or one of several exception members); collectInvokeStream now surfaces an exception member as a real Error instead of silently skipping it on the way to a misleading "no result event" failure. Running the actual test suite (242 pass, 0 fail, 3 pre-existing skips) also caught a real design bug beyond what any shim or manual review found: createOrAdoptInterpreter only ever created a new code interpreter, never adopted an existing one by name, despite the method's own name and config.ts's doc comment promising exactly that adoption. Two AgentCoreSandboxRuntime instances pointed at the same owned interpreter name therefore raced to create two different interpreters, and a session started by one was permanently unreachable from the other's getById -- silently, since GetCodeInterpreterSession just reports ResourceNotFoundException for the wrong codeInterpreterIdentifier. createOrAdoptInterpreter now lists and searches for a same-named interpreter (bounded at 10 pages) before creating one. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H6cB7qLYbvnHjRZXbA4HUH Session-Id: 0f216d95-8216-426e-8ff9-90e28744f278
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds
AgentCoreSandboxRuntimeimplementingSandboxRuntime/WorkflowRuntimefor AWS Bedrock AgentCore's Code Interpreter, following the same
SDK-isolation / capability-reconciliation / provenance discipline as the
Vercel and Modal adapters (
agent/vercel-adapter-0821,agent/modal-adapter-0821).SANDBOX: the March 2026 DNSsandbox-escape research (BeyondTrust Phantom Labs, corroborated by Unit 42
and CSA) is cited inline in
config.ts/runtime.tsand indocs/agentcore.md.SANDBOXrequires an explicit, named opt-in and logsa warning citing the hazard every time it's chosen.
lifecycle(start/stop) is structurally false and the methods areomitted entirely — a session's status is
READY | TERMINATEDonly, noresume path, same shape
modal-adapter-0821documents forSandbox.terminate().warmLeaseis structurally false — AgentCore sessions carry noserver-side tag/label field;
findAllByLabelssearches this runtimeinstance's own in-process registrations only.
src/agentcore/internal/sdk.ts(dynamic import,optional peer deps
@aws-sdk/client-bedrock-agentcore+@aws-sdk/client-bedrock-agentcore-control); SDK-free config/capabilitiesin
config.ts/capabilities.ts.runtime.test.ts,bench.test.ts), all passing.Verified against the real AWS SDK (update from initial draft)
The first push flagged that
npm install/npm testcouldn't be run locallyin the build sandbox. Root cause found and fixed:
~/.npmrcon that host isa symlink into a Dropbox-synced path, and reads of it were hanging/EINTR'ing
inside the sandbox, which stalls npm at startup on every invocation
(
npm --versionincluded) before it ever touches the network — unrelated toAWS. Workaround:
NPM_CONFIG_USERCONFIG=/dev/null npm install.With a real install,
npm run typecheck,npm run build, andnpm testall pass clean (242 pass / 0 fail across the whole package, 3 pre-existing
skips unrelated to this change). Running against the real generated SDK
types (not a hand-written shim) surfaced and fixed three real bugs:
InvokeCodeInterpreterCommand'snameis a closedToolNameenum not aplain string;
CodeInterpreterResult.isErroris optional; and the invokestream is a discriminated union whose exception members were being silently
dropped. Running the real test suite also caught a design bug no shim or
review would have:
createOrAdoptInterpreteronly ever created a newinterpreter, never adopted an existing one by name as its own name and
config.ts's doc comment promised — two runtime instances pointed at thesame owned interpreter name raced to create two different interpreters, and
a session started by one was silently unreachable from the other's
getById. Fixed with a bounded (10-page) list-and-adopt search beforecreate.
Still blocked — not review-final yet
No AWS credentials or IAM execution role are provisioned in the build
environment. This PR ships mocked-only. The live n=1 canary → n=7 bench —
including the idle-billing measurement that's the load-bearing economics
question for this adapter (does AgentCore's "idle time is free" billing
claim cover session memory, or only CPU?) — and the
docs/PRIVATE-sandbox-economics-2026-08-20.mdrow extension are not done, per
docs/agentcore.md#credential-status.Khaliq action items
keys or confirmation that an assumable-role default credential chain is
already reachable — scoped to the
bedrock-agentcore*IAM policy listedin
docs/agentcore.md#credential-status.bedrock-agentcore.amazonaws.com) if the S3 large-file path should beexercised in the live bench.
for the VPC-mode live canary (this adapter's default network mode).
Test plan
src/agentcore/runtime.test.ts+src/agentcore/bench.test.ts, run for real vianpm test: 242/242pass package-wide, 0 fail.
npm run typecheckandnpm run buildboth pass clean against thereal
@aws-sdk/client-bedrock-agentcore*type declarations.🤖 Generated with Claude Code
https://claude.ai/code/session_01H6cB7qLYbvnHjRZXbA4HUH