agentcore invoke silently falls back to SigV4 when CUSTOM_JWT agent has no bearer token

[aidandaly24]

Description

When an agent is configured with authorizerType: CUSTOM_JWT but no OAuth client credentials are stored (i.e., --client-id and --client-secret were not provided during agentcore add agent), agentcore invoke silently falls back to SigV4 authentication instead of failing with a helpful error. The runtime rejects the SigV4 request with a cryptic "Authorization method mismatch" error.

The root cause is in src/cli/commands/invoke/action.ts lines 95-108. When canFetchRuntimeToken() returns false (no credentials configured), the code silently continues without a bearer token. It should instead return an error telling the user they need to either provide --bearer-token or configure client credentials.

Steps to Reproduce

1. Create an agent with CUSTOM_JWT but without --client-id / --client-secret:

   agentcore add agent \
     --type byo \
     --name myAgent \
     --code-location ./app/myAgent \
     --entrypoint main.py \
     --authorizer-type CUSTOM_JWT \
     --discovery-url $DISCOVERY_URL \
     --allowed-clients $CLIENT_ID

2. Deploy: agentcore deploy -y
3. Invoke: agentcore invoke "hello"

Expected Behavior

The CLI should fail immediately with a clear error like:

Agent 'myAgent' is configured for CUSTOM_JWT authentication but no bearer token is available.
Either provide --bearer-token or re-add the agent with --client-id and --client-secret to enable auto-fetch.

Actual Behavior

The CLI silently sends a SigV4 request to a CUSTOM_JWT endpoint, which fails with:

Authorization method mismatch. The agent is configured for a different authorization method than what was used in your request. Check the agent's authorization configuration and ensure your request uses the matching method (OAuth or SigV4)

CLI Version

Latest (reproduced during workshop porting)

Additional Context

The fix is a one-line change in src/cli/commands/invoke/action.ts — add an else branch after the if (canFetch) check:

if (agentSpec.authorizerType === 'CUSTOM_JWT' && !options.bearerToken) {
    const canFetch = await canFetchRuntimeToken(agentSpec.name);
    if (canFetch) {
      // ...existing auto-fetch logic...
    } else {
      return {
        success: false,
        error: `Agent '${agentSpec.name}' is configured for CUSTOM_JWT but no bearer token is available.\nProvide --bearer-token or re-add the agent with --client-id and --client-secret to enable auto-fetch.`,
      };
    }
  }

The same issue likely exists in the TUI invoke path (src/cli/tui/screens/invoke/useInvokeFlow.ts).