feat: clone repos at runtime for fresh code on each review

[jesseturner21]

Summary

• Update review prompt to instruct the agent to clone repos at runtime instead of relying on pre-cloned images
• Ensures the agent always reviews against the latest code

Test plan

• Trigger a manual review via workflow_dispatch and verify repos are cloned fresh
• Verify agent can still read repo files and post PR comments

[github-actions]

Package Tarball

aws-agentcore-0.10.0.tgz

How to install

npm install https://github.com/aws/agentcore-cli/releases/download/pr-991-tarball/aws-agentcore-0.10.0.tgz

[agentcore-cli-automation]

The URL in invoke_command doesn't match the real InvokeAgentRuntimeCommand API shape.

The PR uses:

POST /runtimes/command?agentRuntimeArn={arn}

But the actual API (from the bedrock-agentcore service model) is:

POST /runtimes/{agentRuntimeArn}/commands

Note the differences:

• commands (plural), not command
• agentRuntimeArn is a URI path parameter, not a query-string parameter

You can verify with:

import boto3
c = boto3.client('bedrock-agentcore', region_name='us-east-1')
print(c.meta.service_model.operation_model('InvokeAgentRuntimeCommand').http)
# {'method': 'POST', 'requestUri': '/runtimes/{agentRuntimeArn}/commands', ...}

As written, every clone call will 404.

[agentcore-cli-automation]

invoke_command passes HARNESS_ARN to InvokeAgentRuntimeCommand, but that API expects an agent runtime ARN, not a harness ARN. Harnesses and agent runtimes are distinct resources in AgentCore — the existing InvokeHarness call uses /harnesses/invoke?harnessArn=..., while InvokeAgentRuntimeCommand operates on /runtimes/{agentRuntimeArn}/commands. There is no "harness command" endpoint.

You'll need to either:

1. Resolve the underlying runtime ARN associated with the harness and pass that to InvokeAgentRuntimeCommand (probably requires a new env var / workflow input like AGENT_RUNTIME_ARN), or
2. Drop the runtime cloning approach and instead have the agent itself run git clone / git pull as its first action via its existing shell tool (which already executes inside the harness's runtime session), driven by an instruction in review.md.

Option 2 is likely simpler since it reuses the same session the harness is already operating in and avoids introducing a separate API call.

[agentcore-cli-automation]

Even if the URL and ARN issues are fixed, the clone commands won't actually help the review because the sandbox filesystem isn't shared across sessions.

InvokeAgentRuntimeCommand binds to a session via the X-Amzn-Bedrock-AgentCore-Runtime-Session-Id header. The new invoke_command sets no session id, so:

1. Each of the two git clone calls runs in its own fresh sandbox (so the second clone is in a different container from the first).
2. The subsequent invoke_harness call creates yet another session (SESSION_ID = uuid.uuid4()) with its own sandbox — meaning the agent never sees either clone.

To make this work you'd need to (a) reuse a single session id for both clones and the harness invocation, and (b) confirm that InvokeHarness and InvokeAgentRuntimeCommand actually share filesystem state when given the same session id. If they don't, pre-provisioning via InvokeAgentRuntimeCommand won't be viable and the cloning has to happen inside the harness agent's own shell tool.

[agentcore-cli-automation]

The git clone calls are unauthenticated. aws/agentcore-l3-cdk-constructs is a private repo (an anonymous git clone / git pull against it returns "Repository not found"), so the clone will always fail in the harness runtime unless credentials are provided.

Options:

1. Inject a token into the URL, e.g. https://x-access-token:${GITHUB_TOKEN}@github.com/aws/agentcore-l3-cdk-constructs.git, using a PAT or the workflow's GITHUB_TOKEN (the latter only grants access to the current repo — won't work cross-repo).
2. Use a GitHub App installation token with access to both repos.
3. Configure a git credential helper on the runtime via an earlier invoke_command call.

Whatever path you choose, make sure the token isn't logged — the current code prints the full command (print(f" $ {cmd}")), which would leak it.

[agentcore-cli-automation]

Clone failure is treated as a warning and the script continues:

if not invoke_command(HARNESS_ARN, cmd, REGION):
    print(f"  {YELLOW}Warning: clone failed, agent may lack repo context{RESET}")

Meanwhile system.md still tells the agent the repos are cloned at /opt/workspace/agentcore-cli and /opt/workspace/agentcore-l3-cdk-constructs. If the clones silently fail, the agent will confidently ls/grep paths that don't exist and produce a degraded review without signaling that anything went wrong.

Either:

1. Make a failed clone fatal (sys.exit(1)), so a CI failure makes the problem visible, or
2. Update system.md / review.md to instruct the agent to verify the repos are present (and git clone them itself if not) — which also addresses the session-isolation issue, since the agent's shell tool runs in the harness session.

Also worth noting: if the runtime image already has /opt/workspace/agentcore-cli pre-cloned (as suggested by the PR description "instead of relying on pre-cloned images"), git clone into a non-empty target directory will fail with "destination path already exists and is not an empty directory". A git -C <dir> pull (when present) or rm -rf <dir> && git clone ... would be more robust.

[agentcore-cli-automation]

Reviewed — all the serious issues I found have already been raised in the existing comments (wrong InvokeAgentRuntimeCommand URL shape, harness ARN vs agent runtime ARN mismatch, session isolation between the clone calls and the subsequent invoke_harness call, unauthenticated clone of the private agentcore-l3-cdk-constructs repo, and silent-failure / stale-system.md behavior). No additional blockers from me — resolving those should be enough.