fix(exec): support harness deployments (#1724)

[jesseturner21]

Problem

Fixes #1724. agentcore exec reported "No deployed runtimes found" for harness deployments, while agentcore status and agentcore invoke worked. Deployed resources live in two buckets — resources.runtimes and resources.harnesses — and exec only inspected runtimes.

Root cause

Two layers:

1. Discovery: loadExecContext (and the ExecScreen picker) only enumerated resources.runtimes, so a harness-only project always hit the "No deployed runtimes found" throw.
2. Correct target ARN (found during E2E): a harness must be exec'd via its harness ARN, not the underlying agentRuntimeArn. The Yggdrasill data plane's HarnessLinkedRuntimeValidator blocks ExecuteCommand / InvokeAgentRuntimeCommandShell against a harness-linked runtime ARN ("managed by a harness and cannot be invoked directly"), but routes a harness ARN on the /runtimes/{arn}/... path through the harness exec path (ExecuteCommandActivity.invokeHarnessExecuteCommand → LoopyDP). The first attempt resolved to agentRuntimeArn and got rejected by the service; the corrected fix targets harnessState.harnessArn.

Changes

• loadExecContext (src/cli/commands/exec/action.ts): harness-aware. Considers both buckets; adds --harness <name>; auto-selects a single runtime, else a single harness; errors when both kinds are deployed and no flag is given; resolves harnesses to the harness ARN.
• ExecScreen (src/cli/tui/screens/exec/ExecScreen.tsx): picker lists harnesses (via harness ARN); empty-state message updated.
• --harness flag registered on agentcore exec (command.tsx, types.ts); mutual-exclusion with --runtime.
• Telemetry: added has_harness to exec metrics (command-run.ts schema + all 3 call sites).

Tests

• Unit: new loadExecContext with harnesses block (regression for agentcore exec reports 'No deployed runtimes found' for harness deployments #1724) — auto-select single harness, --harness, not-found, missing harness ARN, multiple-harness ambiguity, runtime+harness ambiguity, --runtime/--harness mutual exclusion. Existing runtime-only tests unchanged.
• Full unit suite: 404 files / 5830 tests passing.

End-to-end validation (real AWS)

Built the tarball (npm run bundle), installed it into a scratch project, agentcore create (harness is the default) + agentcore deploy to a real harness in us-east-1, then exercised exec against the deployed harness. Verbatim output:

$ agentcore status
Harnesses
  execharness: Deployed (v1) (arn:aws:bedrock-agentcore:us-east-1:...:harness/execharness_execharness-v3okdvEDxv)

# Before the ARN fix — resolving to agentRuntimeArn was rejected by the service:
$ agentcore exec "echo hello"
Error: The agent runtime arn:...:runtime/harness_execharness_execharness-ammHHsAwGz is managed by a harness and cannot be invoked directly. Use the InvokeAgentRuntimeCommand API with the relevant harness ID instead.

# After the fix — plain exec auto-selects the harness (by harness ARN):
$ agentcore exec --json "echo hello && uname -m && id -un"
{"success":true,"exitCode":0,"stdout":"hello\naarch64\nroot\n","stderr":""}

# --harness by name:
$ agentcore exec --harness execharness "echo FIXED-byname && pwd"
FIXED-byname
/home

The deployed CloudFormation stack was torn down after validation.

Constraint: Data plane only accepts a harness ARN (not its linked runtime ARN) on the exec/shell path.
Confidence: high
Scope-risk: narrow

[github-actions]

Package Tarball

aws-agentcore-0.23.0.tgz

How to install

gh release download pr-1728-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.23.0.tgz

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-cli-automation]

Nice fix — the harness discovery path is well-structured and the tests cover the important branches. Found two related issues around --harness handling in the command wiring that should be addressed before merging. Both are behavioral (not style), and neither is exercised by the current tests.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	39.63%	14685 / 37050
🔵	Statements	38.9%	15651 / 40229
🔵	Functions	33.73%	2501 / 7413
🔵	Branches	33.21%	9784 / 29455

Generated in workflow #4068 for commit abfedb5 by the Vitest Coverage Report Action

[tejaskash]

Nit / simplification the tail of loadExecContext can collapse from 4 branches to a count check.

The new no-flag path handles "0 deployed", "both kinds exist", "N harnesses", and "N runtimes" as four separate states, plus the runtimeKeys/harnessKeys bookkeeping up top. But exec only ever wants one ARN — the thing that matters is the count of candidates, not which kind they are. Flattening both maps into one list gets you there:

// No flag: exec needs exactly one target.
const candidates = [
  ...Object.values(runtimes).map(r => r.runtimeArn),
  ...Object.values(harnesses).map(h => h.harnessArn),
].filter(Boolean);

if (candidates.length === 0) {
  throw new Error(`No deployed runtimes or harnesses found in target '${targetName}'.`);
}
if (candidates.length > 1) {
  throw new Error(
    `Target '${targetName}' has multiple deploy targets. Specify one with --runtime <name> or --harness <name>: ` +
      [...Object.keys(runtimes), ...Object.keys(harnesses)].join(', ')
  );
}
return { region, runtimeArn: candidates[0]! };

Same behavior, ~30 lines → ~18. The one thing you give up is kind-specific ambiguity wording ("Multiple harnesses..." vs "Multiple agents..."); the merged message lists all names and both flags, so it's always correct regardless of mix. If the distinct wording is intentional UX, ignore this.

The explicit --harness and --runtime name-lookup branches are worth keeping separate as-is — different map, different ARN field, different not-found text. Merging those would be more indirection than it saves.

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[tejaskash]

LGTM