closed

[avi-alpert]

Description

Problem

The agentcore create --name myProj --defaults command creates a project with a harness, when that command's behavior before v0.21.0 was to create a project with an agent. This is a breaking change.

Solution

Update the behavior of --defaults flag to create a project with an agent, to make it consistent with its functionality before v0.21.0.

Type of Change

• Bug fix

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• My changes generate no new 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.21.0.tgz

How to install

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

[agentcore-cli-automation]

The one-line fix is correct: adding 'defaults' to AGENT_PATH_FLAGS ensures isAgentPath() returns true when --defaults is the only routing-relevant flag, restoring the previous behavior of creating an agent project. Without this, agentcore create --name X --defaults would silently fall through to the harness path.

Test coverage gap

The existing --defaults test in src/cli/commands/create/__tests__/create.test.ts:244-252 would not have caught this regression — it only asserts json.success === true and that the project directory exists, both of which are also true on the harness path that the bug routed to. Without strengthening test coverage, this bug class can recur.

Could you add an assertion (or a new test) that verifies the agent path was actually taken? Options:

1. Assert the agent-path JSON shape, e.g. expect(json.agentName).toBe(name) (the harness path returns harnessName, not agentName).
2. Assert the agent artifacts exist on disk, e.g. expect(await exists(join(json.projectPath, 'app', name))).toBeTruthy() — matching the pattern in the "with agent" test at line 81.
3. Add a dedicated test for --defaults alone (no other routing-relevant flags) that exercises just the routing change in this PR.

Any one of these would lock in the fix.

[agentcore-cli-automation]

Fix is correct. See review body for a test-coverage suggestion to lock this in — the existing --defaults integration test passes on both the agent and harness paths, so it wouldn't have caught this regression.

[agentcore-devx-automation]

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

[padmak30]

Please fix the test gap in a follow-up

[agentcore-devx-automation]

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

[agentcore-cli-automation]

LGTM. The fix correctly adds 'defaults' to AGENT_PATH_FLAGS so that agentcore create --name X --defaults routes to the agent path, restoring pre-v0.21.0 behavior. The test gap previously flagged by the automation bot has been addressed in this PR — the updated unit test now asserts json.agentName === name and verifies the agent artifacts exist on disk, which would have caught the regression (the harness path returns harnessName and a different directory layout).