[scooteronce]

Description

A CUSTOM_JWT harness could not be invoked without AWS credentials in v1 (a 0.x regression). invoke --harness rejected --bearer-token, and the harness invoke always called GetHarness and signed InvokeHarness with SigV4.

• harness invoke accepts --bearer-token from stdin (-) or a file (file://<path>), following fix(cli): reject inline bearer tokens in credential flags #2567's convention. Inline values are rejected with SourceResolver.resolveSecret. agentcore invoke --harness picks up the flag.
• invoke --harness <arn> passes the ARN to the harness handler, so the invoke skips GetHarness.
• With a token, createDataClient replaces SigV4 with Smithy's smithy.api#httpBearerAuth scheme (HttpBearerAuthSigner). The SDK's InvokeHarnessCommand and event-stream deserialization are unchanged. The client sends Authorization: Bearer <jwt> and never resolves AWS credentials. CoreClient.data() doesn't cache bearer clients, so a later SigV4 call can't reuse one.
• --bearer-token without --prompt is rejected instead of opening the TUI, because the chat screen still calls GetHarness.

Now this works with no AWS credentials:

az account get-access-token ... --query accessToken -o tsv | \
  agentcore invoke --harness <arn> --bearer-token - --prompt "hello"

Out of scope, follow-ups:

• harness invoke --id <id> --bearer-token still calls GetHarness, because the ID alone doesn't give the ARN.
• Bearer tokens in the interactive harness chat.
• harness shell and runtime invoke still make a control-plane lookup before their bearer call.

Related Issue

Closes #2741

Documentation PR

Not applicable. command.md is regenerated in this PR.

Type of Change

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

Testing

How have you tested the change?

• I ran bun test. 4712 pass, 0 fail.
• I ran the relevant end-to-end tests with bun run test:e2e, or explained why they are not applicable. I didn't run them: they need a deployed harness with a CUSTOM_JWT authorizer and an IdP token, which I don't have. Instead, I ran the built bundle under Node with every AWS credential source removed. echo <jwt> | node dist/index.js invoke --harness <arn> --bearer-token - --prompt hello reached the service and got Harness not found for a placeholder ARN. Before this change, it failed with --bearer-token does not apply to a Harness.
• I ran bun run typecheck
• I ran bun run lint:check
• I ran bun run format:check
• I ran bun run build
• If I modified src/assets/, I updated affected snapshots with bun test <test-file> --update-snapshots and committed them. Not applicable.

New tests:

• src/core/factories.test.ts: the real data client sends Authorization: Bearer and no SigV4 headers, and doesn't call a credentials provider that throws. Without a token, the request is SigV4-signed.
• src/core/core.test.ts: bearer clients are never cached or reused for SigV4 callers.
• src/core/harness.test.ts: the token goes to the client config, not the InvokeHarness input.
• src/handlers/harness/invoke/invoke.test.tsx: the token is read from stdin and from file://. Inline tokens are rejected. Passing --bearer-token without --prompt is rejected.
• src/handlers/project/invoke/index.test.tsx: --harness <arn> --bearer-token - --prompt makes only the InvokeHarness call, in the ARN's region.

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.

[maxrabin]

Tested end to end against a real CUSTOM_JWT harness (Entra ID) on macOS with every AWS credential source removed: --bearer-token file://… returned a reply. The bearer auth works.

Two requests:

1. Add a test that a non-DEFAULT --qualifier reaches InvokeHarness together with --bearer-token.
2. harness invoke --id … --bearer-token still calls GetHarness, so without AWS credentials it fails with a confusing credentials error. Consider rejecting that combination up front and pointing to invoke --harness <arn>.

[scooteronce]

Thanks for testing this against a real harness. Both requests are addressed in eed9dbc:

1. Added a test that a non-DEFAULT --qualifier reaches InvokeHarness with --bearer-token.
2. harness invoke --id … --bearer-token is now rejected up front, with a pointer to agentcore invoke --harness <arn>. Project harness names still work, since the target credentials handle the lookup.