fix(harness): --no-memory disables managed memory instead of omitting it

[aidandaly24]

Description

agentcore add harness --no-memory (gated-off path) wrote a harness spec that omitted the memory config entirely. The AgentCore service treats an omitted memory config as "auto-provision a managed memory", so a "no memory" harness ended up with a managed memory harness_<physicalName>_<hash> it never asked for — and the execution role wasn't scoped for it, so invoke failed:

AccessDeniedException: not authorized to perform bedrock-agentcore:ListEvents
on resource memory/harness_<name>_<hash>

This is a contributing cause of the harness-custom-jwt E2E failure (that test uses --no-memory).

Background. CDK #287 made the harness role grant memory permissions for the omitted case (managedMemory = spec.memory?.mode !== 'disabled') — specifically because the CFN Harness resource couldn't express a memory opt-out at the time, so "no memory" still got a service-auto-created memory that needed the grant. That CFN limitation is gone: Memory: { Disabled: {} } shipped in the CDK (#273, alpha.20+) and the vended project resolves ^0.1.0-alpha.19 → the latest published 0.1.0-alpha.39, which has it.

Fix. buildLegacyMemoryRef now returns { mode: 'disabled' } for --no-memory instead of undefined. That maps to CFN Memory: { Disabled: {} } — no memory is provisioned, no ListEvents grant is needed, no AccessDenied. CLI-only change; the CFN disabled mapping and the schema's disabled arm are already live and ungated.

Related Issue

Closes #1628

Documentation PR

N/A

Type of Change

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

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck (clean)
• I ran npm run lint (0 errors; 31 pre-existing warnings)
• npm run test:integ — add-remove-harness.test.ts 35/35 pass (strengthened the --no-memory test to assert spec.memory.mode === 'disabled')
• Harness primitive unit tests — 283/283 pass

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• 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.20.2.tgz

How to install

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

Looks good to merge.

Verified the fix:

• The legacy (gated-OFF) buildLegacyMemoryRef now correctly emits { mode: 'disabled' } for --no-memory instead of returning undefined, which prevents the AgentCore service from auto-provisioning an unwanted managed memory the harness role can't read.
• The gated-ON path (buildMemoryRef at lines 1216–1218) already handled skipMemory correctly, so the change is correctly scoped to just the legacy path.
• The narrowed condition (skipMemory is the only way to reach the !options.memoryArn && !name branch in legacy mode, since autoCreateMemoryName is otherwise ${name}Memory) means the : undefined fallback is effectively defensive — fine.
• Pulled @aws/agentcore-cdk@0.1.0-alpha.39 (which the vended ^0.1.0-alpha.19 resolves to under npm prerelease semver) and confirmed it both maps mode === 'disabled' → Memory: { Disabled: {} } in harness-cfn-mapping.js and gates the memory role grant via managedMemory = spec.memory?.mode !== 'disabled' in AgentCoreHarnessEnvironment.js. So the CLI-only change is sufficient end-to-end.
• The integ-test addition asserts spec.memory?.mode === 'disabled' against a real on-disk harness.json written by the CLI — no mocking concerns.
• No new telemetry instrumentation needed; the existing return value memoryMode: memoryRef?.mode (line 442) will now naturally report 'disabled' for this path instead of undefined, which is actually an improvement for observability.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	37.03%	13554 / 36602
🔵	Statements	36.3%	14411 / 39696
🔵	Functions	31.69%	2327 / 7343
🔵	Branches	30.78%	8926 / 28994

Generated in workflow #3788 for commit 9b0e903 by the Vitest Coverage Report Action