fix(exec): derive region from the ARN so --runtime needs no project - #1996
Merged
Conversation
`agentcore exec --runtime <arn>` failed with "AWS Targets config file not
found" unless --region was also passed. The ARN short-circuit in
loadExecContext was gated on `startsWith('arn:') && options.region`, so
omitting --region fell through to readAWSDeploymentTargets() /
readDeployedState(), which throw before anything else runs.
The fall-through branch already existed and was labelled "--runtime <arn>
with no --region", but it sat after those reads and used config for one
thing: `options.region ?? targetConfig.region`. That region is field 3 of
the ARN the caller just supplied, so exec was demanding a project, an
aws-targets.json and a completed deploy to recover a value it already had.
This blocks exec for anyone deploying runtimes outside the CLI (CDK,
pipelines, personal stacks), who have no reason to own an agentcore
project at all.
Parse the region from the ARN instead and drop the --region requirement
from both the --runtime and --harness short-circuits. Config is now read
only when a *name* needs resolving, or when the ARN's region field is
empty or malformed. An explicit --region still wins.
regionFromArn moves from operations/jobs/shared/region to a new cli/aws/arn
module so exec does not have to depend on operations/jobs; the jobs path
re-exports it. It lives apart from cli/aws/region because that module
detects the ambient region via env and shared config files, while this is a
pure function over an ARN the caller already holds -- and several jobs tests
replace cli/aws/region wholesale with a detectRegion-only factory mock.
github-actions
Bot
added
size/m
agentcore-devx-automation
Bot
added
the
claude-security-reviewing
Contributor
Package TarballHow to installgh release download pr-1996-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.27.0.tgz |
Contributor
|
Claude Security Review: no high-confidence findings. (run) |
agentcore-devx-automation
Bot
removed
the
claude-security-reviewing
github-actions
Bot
removed
the
agentcore-harness-reviewing
nborges-aws
approved these changes
Aug 13, 2026
nborges-aws
left a comment
nborges-aws
left a comment
Contributor
There was a problem hiding this comment.
LGTM, thanks for fixing!
Contributor
Coverage Report
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
agentcore exec --runtime <full-arn>fails outside an AgentCore project unless--regionis also passed:loadExecContextgated its "explicit ARN, skip deployed state" short-circuit on both flags (options.runtimeArn?.startsWith('arn:') && options.region), so an ARN alone fell through toreadAWSDeploymentTargets()/readDeployedState(), which throw first. The branch further down labelled "--runtime <arn>with no--region" sat after those reads and used config only foroptions.region ?? targetConfig.region— a value already present as field 3 of the ARN that was just supplied. So the CLI demanded a project, a hand-writtenaws-targets.json, and a completed deploy purely to recover something the caller had handed it, which rules outexecfor anyone whose runtimes are deployed by CDK, a pipeline, or a personal stack.This derives the region from the ARN so
--regionis optional, and the short-circuit fires on the ARN alone. Config is now read only when a name has to be resolved. A region-less or malformed ARN still falls through to config as a last resort, so nothing that worked before stops working.--harness <arn>had the identical gate and gets the identical treatment.regionFromArnalready existed insrc/cli/operations/jobs/shared/region.ts, so it is reused rather than rewritten. It moves to a newsrc/cli/aws/arn.tsand is re-exported from its old location to keep the jobs-facing import path stable. Two test files factory-mock the wholeaws/regionmodule, so it could not live there — and the split is cleaner regardless:aws/region.tsdetects the ambient region from env and shared config files, while this is a pure string function over an ARN the caller already holds. Splitting on:rather than matching a partition keeps it correct for GovCloud and China ARNs.Related Issue
Closes #1995
Documentation PR
N/A
Type of Change
Testing
How have you tested the change?
npm run test:unitandnpm run test:integnpm run typechecknpm run lintsrc/assets/, I rannpm run test:update-snapshotsand committed the updated snapshotsUnit: 423/423 files, 6095/6095 tests. Typecheck, lint, prettier and secretlint clean.
test:integdid not run to completion — I stopped it rather than block this PR, so it never printed a summary. Every integ test that did run passed and no failures appeared in the output, but I am not claiming a green integ run. No integ test touchesexec,cli/aws, or the jobs region path; please let CI be the authority there.Also verified end-to-end against a built CLI rather than by unit test alone, in an empty directory with no project:
AWS Targets config file not found at: /private/tmp/exec-fix-check/agentcore/aws-targets.jsonInvokeAgentRuntimecall inus-east-1and fails only on cross-account authorization for a runtime in an account I have no access toThat is the correct terminal state: region resolved from the ARN, config wall gone, no project and no
aws-targets.jsonon disk.New unit tests cover region-from-ARN with config readers mocked to reject and asserted
not.toHaveBeenCalled()(standing in for "no project at all"), an explicit--regionoverriding the ARN,aws-us-govandaws-cnpartitions, and the malformed-ARN fall-back to config.Checklist
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.