fix(e2e): broaden CUSTOM_JWT rejection regex to match service response by notgitika · Pull Request #1622 · aws/agentcore-cli

notgitika · 2026-06-23T20:14:32Z

What

Fixes the harness-custom-jwt.test.ts e2e test that has been failing on mainline since the harness flows were brought into the standard build (PR #1598).

Root Cause

The test deploys a harness with a CUSTOM_JWT authorizer (Cognito), then invokes without an explicit --bearer-token. The CLI auto-attaches a bearer token via the managed OAuth credential. The Cognito access_token lacks a standard aud claim (Cognito uses client_id instead), so the service's HarnessAuthValidator.validateTokenAudience() in YggdrasillDataPlaneService rejects it with:

AgentCore API error (403): {"message":"*** missing required audience claim."}

The test's regex only matched configured for CUSTOM_JWT, authoriz(ation|er).*mismatch, or different.*authorization — none of which match the actual service response.

Fix

Broaden the regex to also accept missing required audience claim. The test's intent (SigV4/invalid-auth is rejected with 403) is unchanged — the exitCode !== 0 assertion still validates the rejection. The negative assertion on line 262 (not.toMatch) remains safe because a successful bearer-token invoke will never contain this message.

Testing

Verified the regex matches the actual error from the CI logs
The negative assertion (expect(output).not.toMatch(...)) on the bearer-token success path is unaffected since a successful invoke returns the agent response, not an auth error

The harness-custom-jwt e2e test asserts that SigV4 invocations against a CUSTOM_JWT harness are rejected. The assertion regex did not account for the actual 403 message returned by the AgentCore service: "missing required audience claim." This occurs because the CLI auto-attaches a bearer token (via the managed OAuth credential) which lacks a standard JWT aud claim — the Cognito access_token uses client_id instead. The harness's HarnessAuthValidator.validateTokenAudience() rejects it with this message rather than the auth-type-mismatch message the regex expected. Broaden the regex to accept this valid rejection variant. The test's intent (SigV4/invalid-auth is rejected with 403) remains unchanged.

agentcore-devx-automation · 2026-06-23T20:15:27Z

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

github-actions · 2026-06-23T20:15:32Z

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

gh release download pr-1622-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

LGTM. Targeted one-line regex fix to an e2e test; the root-cause analysis in the PR description matches what I see in the code:

The harness test exercises the managed-OAuth path (--client-id/--client-secret on add harness), which causes the CLI to auto-attach a bearer token on the "SigV4-only" invoke. That request reaches the service, which rejects on the audience claim — the existing regex didn't cover that response.
The sibling byo-custom-jwt.test.ts patches agentcore.json directly without registering a managed credential, so no token is auto-attached and the rejection happens via a different path that the existing regex already matches. No update needed there.
The negative assertion on line 263 (not.toMatch) remains safe — a successful invoke response won't contain "missing required audience claim".

No source/telemetry impact, e2e-test-only change.

notgitika · 2026-06-23T20:24:53Z

this one makes more sense #1624

notgitika · 2026-06-23T20:14:32Z

What

Fixes the harness-custom-jwt.test.ts e2e test that has been failing on mainline since the harness flows were brought into the standard build (PR #1598).

Root Cause

The test deploys a harness with a CUSTOM_JWT authorizer (Cognito), then invokes without an explicit --bearer-token. The CLI auto-attaches a bearer token via the managed OAuth credential. The Cognito access_token lacks a standard aud claim (Cognito uses client_id instead), so the service's HarnessAuthValidator.validateTokenAudience() in YggdrasillDataPlaneService rejects it with:

AgentCore API error (403): {"message":"*** missing required audience claim."}

The test's regex only matched configured for CUSTOM_JWT, authoriz(ation|er).*mismatch, or different.*authorization — none of which match the actual service response.

Fix

Broaden the regex to also accept missing required audience claim. The test's intent (SigV4/invalid-auth is rejected with 403) is unchanged — the exitCode !== 0 assertion still validates the rejection. The negative assertion on line 262 (not.toMatch) remains safe because a successful bearer-token invoke will never contain this message.

Testing

Verified the regex matches the actual error from the CI logs
The negative assertion (expect(output).not.toMatch(...)) on the bearer-token success path is unaffected since a successful invoke returns the agent response, not an auth error

The harness-custom-jwt e2e test asserts that SigV4 invocations against a CUSTOM_JWT harness are rejected. The assertion regex did not account for the actual 403 message returned by the AgentCore service: "missing required audience claim." This occurs because the CLI auto-attaches a bearer token (via the managed OAuth credential) which lacks a standard JWT aud claim — the Cognito access_token uses client_id instead. The harness's HarnessAuthValidator.validateTokenAudience() rejects it with this message rather than the auth-type-mismatch message the regex expected. Broaden the regex to accept this valid rejection variant. The test's intent (SigV4/invalid-auth is rejected with 403) remains unchanged.

agentcore-devx-automation · 2026-06-23T20:15:27Z

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

github-actions · 2026-06-23T20:15:32Z

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

gh release download pr-1622-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

LGTM. Targeted one-line regex fix to an e2e test; the root-cause analysis in the PR description matches what I see in the code:

The harness test exercises the managed-OAuth path (--client-id/--client-secret on add harness), which causes the CLI to auto-attach a bearer token on the "SigV4-only" invoke. That request reaches the service, which rejects on the audience claim — the existing regex didn't cover that response.
The sibling byo-custom-jwt.test.ts patches agentcore.json directly without registering a managed credential, so no token is auto-attached and the rejection happens via a different path that the existing regex already matches. No update needed there.
The negative assertion on line 263 (not.toMatch) remains safe — a successful invoke response won't contain "missing required audience claim".

No source/telemetry impact, e2e-test-only change.

notgitika · 2026-06-23T20:24:53Z

this one makes more sense #1624

notgitika · 2026-06-23T20:14:32Z

What

Fixes the harness-custom-jwt.test.ts e2e test that has been failing on mainline since the harness flows were brought into the standard build (PR #1598).

Root Cause

The test deploys a harness with a CUSTOM_JWT authorizer (Cognito), then invokes without an explicit --bearer-token. The CLI auto-attaches a bearer token via the managed OAuth credential. The Cognito access_token lacks a standard aud claim (Cognito uses client_id instead), so the service's HarnessAuthValidator.validateTokenAudience() in YggdrasillDataPlaneService rejects it with:

AgentCore API error (403): {"message":"*** missing required audience claim."}

The test's regex only matched configured for CUSTOM_JWT, authoriz(ation|er).*mismatch, or different.*authorization — none of which match the actual service response.

Fix

Broaden the regex to also accept missing required audience claim. The test's intent (SigV4/invalid-auth is rejected with 403) is unchanged — the exitCode !== 0 assertion still validates the rejection. The negative assertion on line 262 (not.toMatch) remains safe because a successful bearer-token invoke will never contain this message.

Testing

Verified the regex matches the actual error from the CI logs
The negative assertion (expect(output).not.toMatch(...)) on the bearer-token success path is unaffected since a successful invoke returns the agent response, not an auth error

The harness-custom-jwt e2e test asserts that SigV4 invocations against a CUSTOM_JWT harness are rejected. The assertion regex did not account for the actual 403 message returned by the AgentCore service: "missing required audience claim." This occurs because the CLI auto-attaches a bearer token (via the managed OAuth credential) which lacks a standard JWT aud claim — the Cognito access_token uses client_id instead. The harness's HarnessAuthValidator.validateTokenAudience() rejects it with this message rather than the auth-type-mismatch message the regex expected. Broaden the regex to accept this valid rejection variant. The test's intent (SigV4/invalid-auth is rejected with 403) remains unchanged.

agentcore-devx-automation · 2026-06-23T20:15:27Z

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

github-actions · 2026-06-23T20:15:32Z

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

gh release download pr-1622-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

LGTM. Targeted one-line regex fix to an e2e test; the root-cause analysis in the PR description matches what I see in the code:

The harness test exercises the managed-OAuth path (--client-id/--client-secret on add harness), which causes the CLI to auto-attach a bearer token on the "SigV4-only" invoke. That request reaches the service, which rejects on the audience claim — the existing regex didn't cover that response.
The sibling byo-custom-jwt.test.ts patches agentcore.json directly without registering a managed credential, so no token is auto-attached and the rejection happens via a different path that the existing regex already matches. No update needed there.
The negative assertion on line 263 (not.toMatch) remains safe — a successful invoke response won't contain "missing required audience claim".

No source/telemetry impact, e2e-test-only change.

notgitika · 2026-06-23T20:24:53Z

this one makes more sense #1624

notgitika · 2026-06-23T20:14:32Z

What

Fixes the harness-custom-jwt.test.ts e2e test that has been failing on mainline since the harness flows were brought into the standard build (PR #1598).

Root Cause

The test deploys a harness with a CUSTOM_JWT authorizer (Cognito), then invokes without an explicit --bearer-token. The CLI auto-attaches a bearer token via the managed OAuth credential. The Cognito access_token lacks a standard aud claim (Cognito uses client_id instead), so the service's HarnessAuthValidator.validateTokenAudience() in YggdrasillDataPlaneService rejects it with:

AgentCore API error (403): {"message":"*** missing required audience claim."}

The test's regex only matched configured for CUSTOM_JWT, authoriz(ation|er).*mismatch, or different.*authorization — none of which match the actual service response.

Fix

Broaden the regex to also accept missing required audience claim. The test's intent (SigV4/invalid-auth is rejected with 403) is unchanged — the exitCode !== 0 assertion still validates the rejection. The negative assertion on line 262 (not.toMatch) remains safe because a successful bearer-token invoke will never contain this message.

Testing

Verified the regex matches the actual error from the CI logs
The negative assertion (expect(output).not.toMatch(...)) on the bearer-token success path is unaffected since a successful invoke returns the agent response, not an auth error

The harness-custom-jwt e2e test asserts that SigV4 invocations against a CUSTOM_JWT harness are rejected. The assertion regex did not account for the actual 403 message returned by the AgentCore service: "missing required audience claim." This occurs because the CLI auto-attaches a bearer token (via the managed OAuth credential) which lacks a standard JWT aud claim — the Cognito access_token uses client_id instead. The harness's HarnessAuthValidator.validateTokenAudience() rejects it with this message rather than the auth-type-mismatch message the regex expected. Broaden the regex to accept this valid rejection variant. The test's intent (SigV4/invalid-auth is rejected with 403) remains unchanged.

agentcore-devx-automation · 2026-06-23T20:15:27Z

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

github-actions · 2026-06-23T20:15:32Z

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

gh release download pr-1622-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

LGTM. Targeted one-line regex fix to an e2e test; the root-cause analysis in the PR description matches what I see in the code:

The harness test exercises the managed-OAuth path (--client-id/--client-secret on add harness), which causes the CLI to auto-attach a bearer token on the "SigV4-only" invoke. That request reaches the service, which rejects on the audience claim — the existing regex didn't cover that response.
The sibling byo-custom-jwt.test.ts patches agentcore.json directly without registering a managed credential, so no token is auto-attached and the rejection happens via a different path that the existing regex already matches. No update needed there.
The negative assertion on line 263 (not.toMatch) remains safe — a successful invoke response won't contain "missing required audience claim".

No source/telemetry impact, e2e-test-only change.

notgitika · 2026-06-23T20:24:53Z

this one makes more sense #1624

notgitika · 2026-06-23T20:14:32Z

What

Fixes the harness-custom-jwt.test.ts e2e test that has been failing on mainline since the harness flows were brought into the standard build (PR #1598).

Root Cause

The test deploys a harness with a CUSTOM_JWT authorizer (Cognito), then invokes without an explicit --bearer-token. The CLI auto-attaches a bearer token via the managed OAuth credential. The Cognito access_token lacks a standard aud claim (Cognito uses client_id instead), so the service's HarnessAuthValidator.validateTokenAudience() in YggdrasillDataPlaneService rejects it with:

AgentCore API error (403): {"message":"*** missing required audience claim."}

The test's regex only matched configured for CUSTOM_JWT, authoriz(ation|er).*mismatch, or different.*authorization — none of which match the actual service response.

Fix

Broaden the regex to also accept missing required audience claim. The test's intent (SigV4/invalid-auth is rejected with 403) is unchanged — the exitCode !== 0 assertion still validates the rejection. The negative assertion on line 262 (not.toMatch) remains safe because a successful bearer-token invoke will never contain this message.

Testing

Verified the regex matches the actual error from the CI logs
The negative assertion (expect(output).not.toMatch(...)) on the bearer-token success path is unaffected since a successful invoke returns the agent response, not an auth error

The harness-custom-jwt e2e test asserts that SigV4 invocations against a CUSTOM_JWT harness are rejected. The assertion regex did not account for the actual 403 message returned by the AgentCore service: "missing required audience claim." This occurs because the CLI auto-attaches a bearer token (via the managed OAuth credential) which lacks a standard JWT aud claim — the Cognito access_token uses client_id instead. The harness's HarnessAuthValidator.validateTokenAudience() rejects it with this message rather than the auth-type-mismatch message the regex expected. Broaden the regex to accept this valid rejection variant. The test's intent (SigV4/invalid-auth is rejected with 403) remains unchanged.

agentcore-devx-automation · 2026-06-23T20:15:27Z

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

github-actions · 2026-06-23T20:15:32Z

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

gh release download pr-1622-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

LGTM. Targeted one-line regex fix to an e2e test; the root-cause analysis in the PR description matches what I see in the code:

The harness test exercises the managed-OAuth path (--client-id/--client-secret on add harness), which causes the CLI to auto-attach a bearer token on the "SigV4-only" invoke. That request reaches the service, which rejects on the audience claim — the existing regex didn't cover that response.
The sibling byo-custom-jwt.test.ts patches agentcore.json directly without registering a managed credential, so no token is auto-attached and the rejection happens via a different path that the existing regex already matches. No update needed there.
The negative assertion on line 263 (not.toMatch) remains safe — a successful invoke response won't contain "missing required audience claim".

No source/telemetry impact, e2e-test-only change.

notgitika · 2026-06-23T20:24:53Z

this one makes more sense #1624

notgitika · 2026-06-23T20:14:32Z

What

Fixes the harness-custom-jwt.test.ts e2e test that has been failing on mainline since the harness flows were brought into the standard build (PR #1598).

Root Cause

The test deploys a harness with a CUSTOM_JWT authorizer (Cognito), then invokes without an explicit --bearer-token. The CLI auto-attaches a bearer token via the managed OAuth credential. The Cognito access_token lacks a standard aud claim (Cognito uses client_id instead), so the service's HarnessAuthValidator.validateTokenAudience() in YggdrasillDataPlaneService rejects it with:

AgentCore API error (403): {"message":"*** missing required audience claim."}

The test's regex only matched configured for CUSTOM_JWT, authoriz(ation|er).*mismatch, or different.*authorization — none of which match the actual service response.

Fix

Broaden the regex to also accept missing required audience claim. The test's intent (SigV4/invalid-auth is rejected with 403) is unchanged — the exitCode !== 0 assertion still validates the rejection. The negative assertion on line 262 (not.toMatch) remains safe because a successful bearer-token invoke will never contain this message.

Testing

Verified the regex matches the actual error from the CI logs
The negative assertion (expect(output).not.toMatch(...)) on the bearer-token success path is unaffected since a successful invoke returns the agent response, not an auth error

The harness-custom-jwt e2e test asserts that SigV4 invocations against a CUSTOM_JWT harness are rejected. The assertion regex did not account for the actual 403 message returned by the AgentCore service: "missing required audience claim." This occurs because the CLI auto-attaches a bearer token (via the managed OAuth credential) which lacks a standard JWT aud claim — the Cognito access_token uses client_id instead. The harness's HarnessAuthValidator.validateTokenAudience() rejects it with this message rather than the auth-type-mismatch message the regex expected. Broaden the regex to accept this valid rejection variant. The test's intent (SigV4/invalid-auth is rejected with 403) remains unchanged.

agentcore-devx-automation · 2026-06-23T20:15:27Z

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

github-actions · 2026-06-23T20:15:32Z

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

gh release download pr-1622-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

LGTM. Targeted one-line regex fix to an e2e test; the root-cause analysis in the PR description matches what I see in the code:

The harness test exercises the managed-OAuth path (--client-id/--client-secret on add harness), which causes the CLI to auto-attach a bearer token on the "SigV4-only" invoke. That request reaches the service, which rejects on the audience claim — the existing regex didn't cover that response.
The sibling byo-custom-jwt.test.ts patches agentcore.json directly without registering a managed credential, so no token is auto-attached and the rejection happens via a different path that the existing regex already matches. No update needed there.
The negative assertion on line 263 (not.toMatch) remains safe — a successful invoke response won't contain "missing required audience claim".

No source/telemetry impact, e2e-test-only change.

notgitika · 2026-06-23T20:24:53Z

this one makes more sense #1624

notgitika · 2026-06-23T20:14:32Z

What

Fixes the harness-custom-jwt.test.ts e2e test that has been failing on mainline since the harness flows were brought into the standard build (PR #1598).

Root Cause

The test deploys a harness with a CUSTOM_JWT authorizer (Cognito), then invokes without an explicit --bearer-token. The CLI auto-attaches a bearer token via the managed OAuth credential. The Cognito access_token lacks a standard aud claim (Cognito uses client_id instead), so the service's HarnessAuthValidator.validateTokenAudience() in YggdrasillDataPlaneService rejects it with:

AgentCore API error (403): {"message":"*** missing required audience claim."}

The test's regex only matched configured for CUSTOM_JWT, authoriz(ation|er).*mismatch, or different.*authorization — none of which match the actual service response.

Fix

Broaden the regex to also accept missing required audience claim. The test's intent (SigV4/invalid-auth is rejected with 403) is unchanged — the exitCode !== 0 assertion still validates the rejection. The negative assertion on line 262 (not.toMatch) remains safe because a successful bearer-token invoke will never contain this message.

Testing

Verified the regex matches the actual error from the CI logs
The negative assertion (expect(output).not.toMatch(...)) on the bearer-token success path is unaffected since a successful invoke returns the agent response, not an auth error

The harness-custom-jwt e2e test asserts that SigV4 invocations against a CUSTOM_JWT harness are rejected. The assertion regex did not account for the actual 403 message returned by the AgentCore service: "missing required audience claim." This occurs because the CLI auto-attaches a bearer token (via the managed OAuth credential) which lacks a standard JWT aud claim — the Cognito access_token uses client_id instead. The harness's HarnessAuthValidator.validateTokenAudience() rejects it with this message rather than the auth-type-mismatch message the regex expected. Broaden the regex to accept this valid rejection variant. The test's intent (SigV4/invalid-auth is rejected with 403) remains unchanged.

agentcore-devx-automation · 2026-06-23T20:15:27Z

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

github-actions · 2026-06-23T20:15:32Z

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

gh release download pr-1622-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

LGTM. Targeted one-line regex fix to an e2e test; the root-cause analysis in the PR description matches what I see in the code:

The harness test exercises the managed-OAuth path (--client-id/--client-secret on add harness), which causes the CLI to auto-attach a bearer token on the "SigV4-only" invoke. That request reaches the service, which rejects on the audience claim — the existing regex didn't cover that response.
The sibling byo-custom-jwt.test.ts patches agentcore.json directly without registering a managed credential, so no token is auto-attached and the rejection happens via a different path that the existing regex already matches. No update needed there.
The negative assertion on line 263 (not.toMatch) remains safe — a successful invoke response won't contain "missing required audience claim".

No source/telemetry impact, e2e-test-only change.

notgitika · 2026-06-23T20:24:53Z

this one makes more sense #1624

notgitika · 2026-06-23T20:14:32Z

What

Fixes the harness-custom-jwt.test.ts e2e test that has been failing on mainline since the harness flows were brought into the standard build (PR #1598).

Root Cause

The test deploys a harness with a CUSTOM_JWT authorizer (Cognito), then invokes without an explicit --bearer-token. The CLI auto-attaches a bearer token via the managed OAuth credential. The Cognito access_token lacks a standard aud claim (Cognito uses client_id instead), so the service's HarnessAuthValidator.validateTokenAudience() in YggdrasillDataPlaneService rejects it with:

AgentCore API error (403): {"message":"*** missing required audience claim."}

The test's regex only matched configured for CUSTOM_JWT, authoriz(ation|er).*mismatch, or different.*authorization — none of which match the actual service response.

Fix

Broaden the regex to also accept missing required audience claim. The test's intent (SigV4/invalid-auth is rejected with 403) is unchanged — the exitCode !== 0 assertion still validates the rejection. The negative assertion on line 262 (not.toMatch) remains safe because a successful bearer-token invoke will never contain this message.

Testing

Verified the regex matches the actual error from the CI logs
The negative assertion (expect(output).not.toMatch(...)) on the bearer-token success path is unaffected since a successful invoke returns the agent response, not an auth error

The harness-custom-jwt e2e test asserts that SigV4 invocations against a CUSTOM_JWT harness are rejected. The assertion regex did not account for the actual 403 message returned by the AgentCore service: "missing required audience claim." This occurs because the CLI auto-attaches a bearer token (via the managed OAuth credential) which lacks a standard JWT aud claim — the Cognito access_token uses client_id instead. The harness's HarnessAuthValidator.validateTokenAudience() rejects it with this message rather than the auth-type-mismatch message the regex expected. Broaden the regex to accept this valid rejection variant. The test's intent (SigV4/invalid-auth is rejected with 403) remains unchanged.

agentcore-devx-automation · 2026-06-23T20:15:27Z

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

github-actions · 2026-06-23T20:15:32Z

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

gh release download pr-1622-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

LGTM. Targeted one-line regex fix to an e2e test; the root-cause analysis in the PR description matches what I see in the code:

The harness test exercises the managed-OAuth path (--client-id/--client-secret on add harness), which causes the CLI to auto-attach a bearer token on the "SigV4-only" invoke. That request reaches the service, which rejects on the audience claim — the existing regex didn't cover that response.
The sibling byo-custom-jwt.test.ts patches agentcore.json directly without registering a managed credential, so no token is auto-attached and the rejection happens via a different path that the existing regex already matches. No update needed there.
The negative assertion on line 263 (not.toMatch) remains safe — a successful invoke response won't contain "missing required audience claim".

No source/telemetry impact, e2e-test-only change.

notgitika · 2026-06-23T20:24:53Z

this one makes more sense #1624

notgitika requested a review from a teamJune 23, 2026 20:14

github-actionsBot added the size/xs PR size: XS label Jun 23, 2026

notgitika had a problem deploying to e2e-testing June 23, 2026 20:14 — with GitHub Actions Failure

github-actionsBot added the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

agentcore-devx-automationBot added the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-devx-automationBot removed the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-cli-automation approved these changes Jun 23, 2026
View reviewed changes

github-actionsBot removed the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

notgitika closed this Jun 23, 2026

notgitika requested a review from a teamJune 23, 2026 20:14

github-actionsBot added the size/xs PR size: XS label Jun 23, 2026

notgitika had a problem deploying to e2e-testing June 23, 2026 20:14 — with GitHub Actions Failure

github-actionsBot added the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

agentcore-devx-automationBot added the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-devx-automationBot removed the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-cli-automation approved these changes Jun 23, 2026
View reviewed changes

github-actionsBot removed the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

notgitika closed this Jun 23, 2026

notgitika requested a review from a teamJune 23, 2026 20:14

github-actionsBot added the size/xs PR size: XS label Jun 23, 2026

notgitika had a problem deploying to e2e-testing June 23, 2026 20:14 — with GitHub Actions Failure

github-actionsBot added the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

agentcore-devx-automationBot added the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-devx-automationBot removed the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-cli-automation approved these changes Jun 23, 2026
View reviewed changes

github-actionsBot removed the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

notgitika closed this Jun 23, 2026

notgitika requested a review from a teamJune 23, 2026 20:14

github-actionsBot added the size/xs PR size: XS label Jun 23, 2026

notgitika had a problem deploying to e2e-testing June 23, 2026 20:14 — with GitHub Actions Failure

github-actionsBot added the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

agentcore-devx-automationBot added the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-devx-automationBot removed the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-cli-automation approved these changes Jun 23, 2026
View reviewed changes

github-actionsBot removed the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

notgitika closed this Jun 23, 2026

notgitika requested a review from a teamJune 23, 2026 20:14

github-actionsBot added the size/xs PR size: XS label Jun 23, 2026

notgitika had a problem deploying to e2e-testing June 23, 2026 20:14 — with GitHub Actions Failure

github-actionsBot added the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

agentcore-devx-automationBot added the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-devx-automationBot removed the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-cli-automation approved these changes Jun 23, 2026
View reviewed changes

github-actionsBot removed the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

notgitika closed this Jun 23, 2026

notgitika requested a review from a teamJune 23, 2026 20:14

github-actionsBot added the size/xs PR size: XS label Jun 23, 2026

notgitika had a problem deploying to e2e-testing June 23, 2026 20:14 — with GitHub Actions Failure

github-actionsBot added the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

agentcore-devx-automationBot added the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-devx-automationBot removed the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-cli-automation approved these changes Jun 23, 2026
View reviewed changes

github-actionsBot removed the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

notgitika closed this Jun 23, 2026

notgitika requested a review from a teamJune 23, 2026 20:14

github-actionsBot added the size/xs PR size: XS label Jun 23, 2026

notgitika had a problem deploying to e2e-testing June 23, 2026 20:14 — with GitHub Actions Failure

github-actionsBot added the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

agentcore-devx-automationBot added the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-devx-automationBot removed the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-cli-automation approved these changes Jun 23, 2026
View reviewed changes

github-actionsBot removed the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

notgitika closed this Jun 23, 2026

notgitika requested a review from a teamJune 23, 2026 20:14

github-actionsBot added the size/xs PR size: XS label Jun 23, 2026

notgitika had a problem deploying to e2e-testing June 23, 2026 20:14 — with GitHub Actions Failure

github-actionsBot added the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

agentcore-devx-automationBot added the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-devx-automationBot removed the claude-security-reviewing Claude Code /security-review in progress label Jun 23, 2026

agentcore-cli-automation approved these changes Jun 23, 2026
View reviewed changes

github-actionsBot removed the agentcore-harness-reviewing AgentCore Harness review in progress label Jun 23, 2026

notgitika closed this Jun 23, 2026

Uh oh!

Conversation

notgitika commented Jun 23, 2026

What

Root Cause

Fix

Testing

Uh oh!

agentcore-devx-automationBot commented Jun 23, 2026

Uh oh!

github-actionsBot commented Jun 23, 2026

Package Tarball

How to install

Uh oh!

agentcore-cli-automation left a comment

Choose a reason for hiding this comment

Uh oh!

notgitika commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

notgitika commented Jun 23, 2026

What

Root Cause

Fix

Testing

Uh oh!

agentcore-devx-automationBot commented Jun 23, 2026

Uh oh!

github-actionsBot commented Jun 23, 2026

Package Tarball

How to install

Uh oh!

agentcore-cli-automation left a comment

Choose a reason for hiding this comment

Uh oh!

notgitika commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

notgitika commented Jun 23, 2026

What

Root Cause

Fix

Testing

Uh oh!

agentcore-devx-automationBot commented Jun 23, 2026

Uh oh!

github-actionsBot commented Jun 23, 2026

Package Tarball

How to install

Uh oh!

agentcore-cli-automation left a comment

Choose a reason for hiding this comment

Uh oh!

notgitika commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!