aws-samples / aws-samples/agents4energy

Remove agentcore_code_interpreter sandbox tool from MyHarness to eliminate the git-auth environment split (see #190)

Open
#191 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.