fix: route Harness invoke exec through command API

[aidandaly24]

Description

Route the documented agentcore invoke --exec --harness and
--harness-arn paths through InvokeAgentRuntimeCommand instead of sending
the command as a conversational InvokeHarness message.

This extracts the existing Runtime exec behavior into a shared invoke helper,
preserving streaming output, JSON envelopes, exit codes, timeout status,
headers, bearer tokens, and invocation logging for Runtime and Harness targets.

Related Issue

Closes #2096

Documentation PR

N/A. This fixes the CLI to match the existing AgentCore Harness documentation.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Additional verification:

• Added three focused regression tests for configured Harness, direct Harness ARN, and unchanged Runtime exec behavior.
• Focused Harness exec tests: 3 passed.
• Invoke/exec action and command tests: 165 passed; the spawned-CLI integration file fails with empty child output on this host and reproduces unchanged on an untouched origin/main worktree.
• Exact npm run test:unit: 6,048 passed; 105 sandbox/baseline failures reproduce on untouched origin/main (spawned CLI output, read-only home, and unavailable ports).
• Exact npm run test:integ: 34 passed, 251 skipped; 58 failures have the same empty spawned-CLI output signature and are unrelated to the changed invoke action.
• npm run build: passed.
• npm run format:check: passed.
• Live Harness deploy in account 603141041947, us-east-1:
  invoke --exec --harness ExecHarness "printf harness-exec-ok" returned
  stdout harness-exec-ok, exit code 0, and status COMPLETED.
• Live Runtime regression in the same account and Region:
  invoke --exec --runtime RuntimeExecFix "printf runtime-exec-ok" returned
  stdout runtime-exec-ok, exit code 0, and status COMPLETED.
• Both disposable CloudFormation stacks and resources were deleted and absence was verified.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-devx-automation]

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

[github-actions]

Package Tarball

aws-agentcore-0.28.0.tgz

How to install

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

[agentcore-devx-automation]

AgentCore Harness Review

Verdict: Looks good

Nice, focused fix. Previously invoking a harness with --exec (both --harness and --harness-arn paths) silently fell through to normal model invocation with the shell command as the prompt; this PR routes those cases through executeBashCommand via a new shared handleInvokeExec helper.

Points I verified:

• Runtime exec preserved. The extracted handleInvokeExec in src/cli/commands/invoke/action.ts is a straight lift of the previous inline block (same stdout/stderr streaming, same JSON vs non-JSON return shape, same logger.logResponse / logger.logError behavior). The runtime call site at line 391 still runs after payment/auto-session validation, so no ordering regressions.
• Harness path ordering is correct. In handleHarnessInvoke, the exec branch (line 1056) sits after the deployed-state lookup, prompt validation, and the CUSTOM_JWT bearer-token auto-fetch, so an exec against a JWT-protected harness will still get its token injected. options.sessionId is normalized at line 1013 before being forwarded, so the exec helper always sees a concrete session id.
• handleHarnessInvokeByArn correctly gates on options.exec after prompt validation and generates a session id before delegating; it intentionally skips buildHarnessBaseOpts, which is fine since executeBashCommand doesn't consume harness model options.
• Test coverage exercises all three call sites (harness by name, harness by ARN, runtime) and asserts the exact executeBashCommand payload plus that invokeHarness is not called — which is the actual invariant this bug requires.

Minor note (not a blocker): action-harness-exec.test.ts mocks the entire ../../../aws index and ../resolve, which is heavier than the "mock at I/O boundaries only" guidance. resolveInvokeTarget is pure enough to run against fixture InvokeContext data, and only executeBashCommand / invokeHarness truly need mocking. Worth tightening next time this file is touched, but the current mocks don't hide anything material for what's being asserted here.

No new telemetry needed — this is a bug fix that reuses the existing exec path; command-level telemetry at the CLI entrypoint continues to cover it.