feat(fetch): support harness in fetch access (CLI + TUI)

[tejaskash]

Summary

Adds harness as a resource type for fetch access, so users can retrieve a CUSTOM_JWT bearer token for a deployed harness — both from the CLI (fetch access --type harness --name <name>) and the interactive TUI picker. Builds on the existing fetchHarnessToken operation (already used by invoke auto-fetch); this exposes it through the fetch command surface.

What changed

CLI

• commands/fetch/types.ts — FetchResourceType += 'harness'
• commands/fetch/action.ts — handleFetchHarnessAccess dispatch; the agent and harness handlers now share one fetchTokenAccess helper (they were near-identical)
• commands/fetch/command.tsx — --type / --name / description help text cover harness

TUI

• operations/fetch-access/list-harnesses.ts — new listHarnesses (project registry ∩ deployed-state, reads each harness.json for authorizerType); mirrors listAgents
• operations/fetch-access/{types,index}.ts — HarnessInfo type + exports
• tui/screens/fetch-access/useFetchAccessFlow.ts — loads harnesses alongside gateways/agents; routes harness fetch through fetchHarnessToken
• tui/screens/fetch-access/FetchAccessScreen.tsx — labels the harness resource type

Testing

Unit: 48 passing across fetch-access, including 6 new harness cases (3 CLI action, 3 TUI flow).

End-to-end against real AWS (account 346532552948 / us-west-2):

1. Deployed a CUSTOM_JWT harness backed by a Cognito user pool, with the OAuth credential stored in Bedrock AgentCore Identity (create-oauth2-credential-provider).
2. fetch access --type harness --name <name> → success: true, returned a valid Cognito-issued JWT (verified claims: correct issuer, client_id, scope=agentcore/invoke, token_use=access).
3. TUI fetch flow → harness appears in the picker as Harness [JWT], selecting it fetches and displays the same valid token.
4. Verified for both a TUI-created harness and a CLI-created harness.

Notes

• An AWS_IAM harness has no token to fetch — it surfaces the existing "use SigV4" guidance (same UX as the agent path). Token fetch applies only to CUSTOM_JWT harnesses with a managed OAuth credential.
• listHarnesses reads each harness.json for authorizerType (the project registry entry only carries name/path).

[agentcore-devx-automation]

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

[github-actions]

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

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

[agentcore-cli-automation]

Nice cleanup factoring fetchTokenAccess out of the agent and harness paths. A couple of real issues to address before merge — see inline comments. The main one: --identity-name is silently ignored for harnesses because fetchHarnessToken doesn't accept that option, even though the CLI advertises the flag for all token-bearing resources.

---

One additional note (not file in this PR, so flagging here):

Telemetry — ResourceType in src/cli/telemetry/schemas/common-shapes.ts:93 is z.enum(['gateway', 'agent']) and backs the fetch.access resource_type attribute (see command-run.ts:173). Adding harness means that enum needs 'harness' for any future emission to be valid.

Separately, I couldn't find any actual cli.command_run emission for fetch.access — the schema entry exists but commands/fetch/command.tsx doesn't wrap the handler with withCommandRunTelemetry. That's a pre-existing gap, but per src/cli/telemetry/README.md adding telemetry to new features is expected. Worth wiring up while you're here so the new harness path doesn't go unobserved.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	37.03%	13545 / 36572
🔵	Statements	36.3%	14398 / 39662
🔵	Functions	31.66%	2324 / 7339
🔵	Branches	30.79%	8921 / 28969

Generated in workflow #3760 for commit 2ad7236 by the Vitest Coverage Report Action

[agentcore-devx-automation]

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

[agentcore-cli-automation]

Looks good to merge from my pass. The three inline issues from the previous review (--identity-name silently dropped for harnesses, the silent AWS_IAM fallback in listHarnesses, and the weak authType: string typing) all landed cleanly in e3be685 with tests to back the identityName forwarding.

The only outstanding item is the telemetry note from the previous review summary — it wasn't addressed and isn't a code-change blocker in this PR, but worth tracking:

• ResourceType in src/cli/telemetry/schemas/common-shapes.ts:93 is z.enum(['gateway', 'agent']); if/when fetch.access actually emits, harness will fail schema validation.
• commands/fetch/command.tsx doesn't wrap the action with withCommandRunTelemetry, so the new harness path (and the existing agent/gateway paths) go unobserved despite a FetchAccessAttrs schema entry already existing for it.

Both are pre-existing gaps that this PR widens rather than introduces. Happy to see them addressed in a follow-up if you'd rather keep this PR scoped.

[tejaskash]

Addressed the telemetry note from the review body in 2ad7236:

• ResourceType enum now includes 'harness' (src/cli/telemetry/schemas/common-shapes.ts) — so a fetch.access emission with resource_type=harness validates instead of being dropped.
• Wired withCommandRunTelemetry into fetch access — the command previously emitted no cli.command_run at all. It now records resource_type. handleFetchAccess runs exactly once inside the wrapper; its string-error shape is adapted to the Result {success, error: Error} the telemetry layer expects (used only for exit_reason/error_name), while the original result drives output.

The three inline issues (--identity-name forwarding, AWS_IAM fallback, HarnessInfo.authType typing) were addressed earlier in e3be685. All review items are now resolved. 131 tests pass across telemetry + fetch + tui-fetch suites.

[agentcore-devx-automation]

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