`aws codeartifact describe-package-version` provides no output

[ericavh-evercommerce]

Describe the bug

aws codeartifact describe-package-version does not appear to make any requests.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

describe-package-version should return package version details.

Current Behavior

The describe-package-version command returns aws-cli/2.36.47 Python/3.14.7 Darwin/25.5.0 source/arm64 or similar. This behavior is consistent across multiple domains and packages. It does not appear to be dependent on the package being an upstream or locally published package. The AWS console appears to be able to fetch package version details. I have reproduced this behavior in AWS CloudShell while using an Administrator session.

Running describe-package-version with the --debug flag produces output like:

2026-09-17 10:07:33,680 - MainThread - awscli.clidriver - DEBUG - CLI version: aws-cli/2.36.47 Python/3.14.7 Darwin/25.5.0 source/arm64
2026-09-17 10:07:33,680 - MainThread - awscli.clidriver - DEBUG - Arguments entered to CLI: ['codeartifact', 'describe-package-version', '--domain', 'my-domain', '--repository', 'my-repository', '--format', 'maven', '--package', 'package-name', '--namespace', 'namespace', '--version', 'package-version', '--debug']
2026-09-17 10:07:33,693 - MainThread - awscli.lazy_emitter - DEBUG - Lazy-initializing plugin awscli.customizations.waiters.register_add_waiters for event building-command-table.main
2026-09-17 10:07:33,693 - MainThread - awscli.lazy_emitter - DEBUG - Lazy-initializing plugin awscli.alias.register_alias_commands for event building-command-table.main
2026-09-17 10:07:33,693 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <function add_waiters at 0x10a3a99b0>
2026-09-17 10:07:33,693 - MainThread - botocore.hooks - DEBUG - Event building-command-table.main: calling handler <bound method AliasSubCommandInjector.on_building_command_table of <awscli.alias.AliasSubCommandInjector object at 0x10a3c4c20>>
2026-09-17 10:07:33,693 - MainThread - botocore.loaders - DEBUG - Loading JSON file: /opt/homebrew/Cellar/awscli/2.36.47/libexec/lib/python3.14/site-packages/awscli/data/cli.json
aws-cli/2.36.47 Python/3.14.7 Darwin/25.5.0 source/arm64

Running describe-package-version help results in the help page being displayed as expected.

Reproduction Steps

I am running approximately the following bash:

DOMAIN='my-domain'
REPOSITORY='my-repository'
# I have observed this behavior with npm packages as well
PACKAGE_FORMAT='maven'
PACKAGE_NAMESPACE='public-package-namespace'
PACKAGE_NAME='public-package-name'

# This command behaves as expected
version=$(aws codeartifact list-package-versions \
  --domain "${DOMAIN}" \
  --repository "${REPOSITORY}" \
  --format "${PACKAGE_FORMAT}" \
  --namespace "${PACKAGE_NAMESPACE}" \
  --package "${PACKAGE_NAME}" \
  --output 'text' \
  --query 'defaultDisplayVersion')

# Note that the second command is using the same parameter values
# as the previous command which succeeded, indicating that the package
# exists. Note that the version being used is the version supplied by the
# `list-package-versions` command
aws codeartifact describe-package-version \
  --domain "${DOMAIN}" \
  --repository "${REPOSITORY}" \
  --format "${PACKAGE_FORMAT}" \
  --namespace "${PACKAGE_NAMESPACE}" \
  --package "${PACKAGE_NAME}" \
  --version "${version}"

Possible Solution

No response

Additional Information/Context

No response

CLI version used

aws-cli/2.36.47 Python/3.14.7 Darwin/25.5.0 source/arm64, aws-cli/2.36.45 Python/3.14.6 Linux/6.1.182-227.379.amzn2023.x86_64 exec-env/CloudShell exe/x86_64.amzn.2023

Environment details (OS name and version, etc.)

macOS 26.5.2, Amazon Linux 2023.12.20260727

[shashankvarma499]

Thanks for the detailed report. I can reproduce the mechanism on current v2 source.

Root cause: MainArgParser._build registers a top-level --version option with argparse's builtin action="version" (awscli/argparser.py, lines 154-159). Because argparse processes registered optionals anywhere in the argument list, the top-level parse in CLIDriver.main (awscli/clidriver.py, line 222, parser.parse_known_args(args)) consumes --version before the command chain is ever dispatched, prints the CLI version, and exits with code 0. The debug log in the report matches exactly: the arguments are logged, then the version line is printed, and ServiceCommand/ServiceOperation never runs. describe-package-version is one of the few operations whose service model defines an exact --version parameter, which is why it collides.

I verified this with a minimal argparse reproduction of the same parser structure: parsing ['codeartifact', 'describe-package-version', '--version', '1.0.0', ...] with the top-level parser fires the version action and exits 0.

Two directions I can see:

1. Handle the global version flag in CLIDriver.main instead of in argparse: remove the action="version" registration and print the version there only when --version appears before any command token (the behavior of aws --version today). A --version after a command token then stays in remaining and is parsed by the operation parser, which already defines the parameter from the service model. This is the smallest change, but commands without a version parameter would then reject --version as an unknown option instead of printing the CLI version.
2. Preserve the current behavior for other commands: register the top-level --version with nargs='?' and a custom action that records the flag and its value, then in main() re-inject --version <value> into remaining when a command follows, so only a bare global flag with no command after it prints the version.

Tests I would add (in tests/unit/, alongside the existing clidriver/argparser tests): aws --version still prints the version and exits 0; aws codeartifact describe-package-version --version <ver> reaches the operation parser with version=<ver> (assert the version action does not fire and the argument lands on the operation namespace); and a control case for a command without a version parameter under whichever option you prefer.

I am happy to implement either direction, or another approach the team prefers, and to open the PR against v2 once the approach is agreed.

[ericavh-evercommerce]

Realized my error. Correct parameter is --package-version not --version.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.