fix(templates): refresh Python dependencies and container hygiene

[aidandaly24]

Description

• Allow patched MCP 1.x releases (>=1.28.1,<2) in generated agent and MCP tool projects.
• Raise older AgentCore Python SDK floors to 1.18.1 and enable its declared Strands integration dependency in Strands templates.
• Install available Debian updates in the Python container template before switching to the runtime user.
• Disable uv caching and remove the global uv installation after the final frozen sync.

Frozen dependency installation, non-root execution, Runtime ports, and direct Python startup are retained. The separate Bedrock Managed Agents image is unchanged because it uses uv at runtime.

Related Issue

Security-related dependency refresh based on already-published advisories. No public security issue was opened, following the repository's CONTRIBUTING guidance.

Public references:

• MCP fixes
• AgentCore Python SDK fix
• Debian OpenSSL update

Documentation PR

Not applicable. No documentation changes are included.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

• Full unit suite with coverage: npm run test:unit -- --maxWorkers=4, 6,342 passed.
• Integration suite against the built CLI: npm exec -- vitest run --project integ --maxWorkers=4, 355 passed and 1 skipped.
• Final dependency/rendered-Dockerfile regressions and affected asset snapshots were checked after the Strands integration follow-up.
• Fresh generated Strands and MCP projects resolve SDK 1.24.0, MCP 1.30.0, and SDK-compatible Strands 1.57.1.
• Built a generated Strands image using docker build --pull --no-cache --platform linux/amd64.
• Final image inspection confirms libssl3t64 3.5.7-1~deb13u3, no uv/uvx executables, and no /root/.cache/uv.
• Default startup command returns /ping Healthy as UID 1000, with external networking disabled and dummy credentials.

The full suites ran before the final SDK/Strands metadata follow-up; that follow-up was verified with the generated-project regressions, fresh resolution, rebuilt image, and startup check. This is local x86 container verification, not an ARM64 AWS deployment or a new Inspector scan. No model invocation was attempted in the isolated startup smoke.

• I ran npm run test:unit and the equivalent built-CLI integration suite
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I updated and committed the affected snapshots
• I ran npm run format:check and npm run build

Checklist

• I have read the CONTRIBUTING document
• I have added necessary regression tests
• No documentation changes are required
• No new example is required for this template-only fix
• My changes generate no new CLI warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-devx-automation]

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

[github-actions]

Package Tarball

aws-agentcore-0.31.0.tgz

How to install

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

[agentcore-devx-automation]

AgentCore Harness Review

Verdict: Looks good

This is a well-scoped dependency and base-image refresh. Spot checks:

• Dockerfile template changes (src/assets/container/python/Dockerfile): OS upgrade step runs before USER bedrock_agentcore, UV_NO_CACHE=1 is set before both uv sync invocations, and /usr/local/bin/python -m pip uninstall -y uv runs after the final sync. The path matches where pip install --no-cache-dir uv places uv on public.ecr.aws/docker/library/python:3.12-slim-trixie.
• pyproject.toml updates line up with the new python-dependencies.test.ts matrix. Snapshots and dependency test both pin >= 1.28.1, < 2.0.0 for mcp and >= 1.18.1 for bedrock-agentcore, including the correct [strands-agents] and [a2a,strands-agents] extras.
• Tests use copyAndRenderDir against real temp dirs rather than mocks — good.
• uv.lock is generated at agentcore create time by installDependencies (plain uv sync), so no lockfile needs to ship in the templates; uv sync --frozen in the Dockerfile will have a fresh lock to consume.

Non-blocking observation

The hardcoded fallback Dockerfile in src/cli/commands/import/actions.ts (around lines 414–436, only used when the starter-toolkit Dockerfile is missing) was not updated alongside the template: it still omits the apt-get upgrade, UV_NO_CACHE=1, and the trailing pip uninstall -y uv. If keeping these two code paths aligned matters for imported projects, consider a follow-up to update it (or extract a shared source). Not blocking this PR.

[agentcore-devx-automation]

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

[agentcore-devx-automation]

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

[notgitika]

Review findings:

1. Blocking: the shared Python Dockerfile is hardened, but other reachable container-generation paths still emit the old recipe:
   • src/cli/commands/import/actions.ts around lines 414–430
   • src/cli/commands/export/harness-action.ts around lines 378–382 and 488–510

These paths still install uv without UV_NO_CACHE and leave uv in the final image. The import path using the standard Python base also omits the OS package upgrade. Imported/exported container projects can therefore retain the OpenSSL, uv-cache, and uv-binary Inspector findings this patch is intended to address. Please reuse the shared Dockerfile implementation where possible, or apply equivalent hardening and add regression coverage for these paths. For arbitrary custom/containerUri bases, the generated guidance should explicitly require refreshing the base OS packages as appropriate.

2. The patch only changes newly generated project assets. Updating the CLI and redeploying an existing project does not rewrite its pyproject.toml, uv.lock, or Dockerfile, so the customer from the linked ticket will remain affected unless they manually update the constraints, run uv lock --upgrade, apply the Dockerfile changes, and rebuild without stale layers. Please ensure those migration steps are captured in the release/ticket guidance (or provide migration automation) rather than describing a CLI upgrade/redeploy alone as remediation.