aws-samples / aws-samples/agents4energy
Remove agentcore_code_interpreter sandbox tool from MyHarness to eliminate the git-auth environment split (see #190)
- Dominant language
- TypeScript
- Stars
- 48
- Forks
- 68
- PR merge metrics
- No merged PRs in 30d
Description
## Summary
Remove the built-in `agentcore_code_interpreter` sandbox tool from the `MyHarness` definition. It is the root of the confusion diagnosed in #190: the harness runs the model's shell commands in an isolated code-interpreter sandbox that is a *different environment* from both the harness runtime shell and the `InvokeAgentRuntimeCommand` session the webhook git-auth step seeds — so git setup silently doesn't reach where the agent actually runs commands, producing `git: command not found` while the setup exec reports `exitCode=0`.
Dropping the code-interpreter tool eliminates that split-brain: with no built-in sandbox, there is one clear story for where/whether the harness can run shell commands.
## Where it's configured
Inlined as a literal `CfnHarness`-shaped object in [`web/amplify/backend.ts:66-69`](web/amplify/backend.ts#L66-L69):
```ts
tools: [
{ type: 'agentcore_browser', name: 'browser', config: { agentCoreBrowser: {} } },
{ type: 'agentcore_code_interpreter', name: 'code-interpreter', config: { agentCoreCodeInterpreter: {} } },
],
```
(There is no `harness.json`; per `docs/agentic-architecture.md`, everything about `MyHarness` except the system prompt is inlined here.)
## Scope of change
- Remove the `agentcore_code_interpreter` entry from `harnessSpecs[MyHarness].tools` in `web/amplify/backend.ts`.
- Decide whether `agentcore_browser` stays (this issue is specifically about the code sandbox; browser is not implicated in the git confusion, so leave it unless there's a separate reason to drop it).
- Redeploy the harness. Confirm the harness still synthesizes and invokes with the tool removed.
## Docs to update after the change
- `docs/agentic-architecture.md:43` — "Built-in tools: Browser, Code Interpreter"
- `docs/agentic-architecture.md:57` — the `agentcore_browser`, `agentcore_code_interpreter` table row
- `docs/agentic-architecture.md:225-226` — the invocation diagram listing `agentcore_code_interpreter`
## Follow-on implications (call out, don't necessarily solve here)
- The webhook path's whole reason for seeding git/gh via `InvokeAgentRuntimeCommand` was to give the code-interpreter agent write access. With the sandbox gone, that git-auth prep step and the `` prompt block in `agent-webhook-invoke-agent/handler.ts` need rethinking — if the harness can no longer run git at all, cloning/pushing/`gh pr create` from `MyHarness` isn't possible and the webhook flow's expectations change. Track that in #190 (or a linked follow-up) rather than silently leaving a dead git-auth step.
## Related
- Blocks/relates to #190 (the `git: command not found` diagnosis). This issue removes the confusing sandbox; #190 covers what the webhook git-auth flow should do afterward.
Contributor guide
Research direction
Start at web/amplify/backend.ts:66-69 and read docs/agentic-architecture.md, especially lines 43, 57, and 225-226. Remove only the agentcore_code_interpreter entry, keep the browser entry, update the documented tool list and diagram, then redeploy and confirm MyHarness still synthesizes and invokes. Leave webhook git-auth implications for #190 or a follow-up.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, git, typescript
- Domain
- backend, cloud, documentation
- Issue type
- Refactor
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100