aws / aws/agentcore-cli

[Feature Request] Support exclude patterns for CodeZip codeLocation bundling

Open
#948 0 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
TypeScript
Stars
283
Forks
95
Avg merge
1d 2h
Merged PRs (30d)
183

Description

### Description

## Problem

When using `codeLocation: "./"` in `agentcore.json` for a monorepo project,
`agentcore deploy` bundles everything in the directory — including:

- `agentcore/cdk/node_modules/` (272MB)
- `agentcore/cdk/cdk.out/` (779MB)
- `agentcore/.cache/` (1.4GB of previous staging builds)
- `infrastructure/` (CDK stacks, Lambda layers with x86_64 binaries)

This causes:
1. **CREATE_FAILED** with "artifact contains binary files incompatible with Linux ARM64"
because x86_64 `.so` files from unrelated directories get included
2. **250MB package size limit exceeded** even though actual agent code is ~400KB
3. Extremely slow deploys (uploading GB of unnecessary files)

## Current Workaround

Manually `rm -rf agentcore/.cache agentcore/cdk/cdk.out` before every deploy.
This is fragile and error-prone.

## Requested Feature

Support an exclude mechanism, any of:
1. `.agentcoreignore` file (like `.dockerignore` / `.gitignore`)
2. `exclude` array in `agentcore.json` runtime config
3. Respect `.gitignore` when building the CodeZip artifact

## Environment
- agentcore CLI version: (run `agentcore --version`)
- OS: macOS ARM64
- Build type: CodeZip
- Python: 3.12

### Acceptance Criteria

1. The CLI MUST automatically exclude its own build artifacts from the CodeZip bundle:
- agentcore/.cache/
- agentcore/cdk/cdk.out/
- agentcore/cdk/node_modules/
These should NEVER be included regardless of codeLocation setting.

2. The CLI SHOULD support a user-defined exclude mechanism via at least ONE of:
a) An .agentcoreignore file (same syntax as .gitignore)
b) An "exclude" array in the runtime config in agentcore.json:
{
"name": "my_agent",
"codeLocation": "./",
"exclude": ["infrastructure/**", "tests/**", "*.md"]
}
c) Respect the project's .gitignore when building the CodeZip artifact

3. The CLI SHOULD warn the user when the CodeZip artifact exceeds 200MB
(before hitting the 250MB hard limit), listing the largest directories
included so the user can identify what to exclude.

4. The CLI MUST NOT include files with incompatible binary architectures
(e.g. x86_64 .so files when deploying to ARM64 runtime). Either:
- Detect and skip them with a warning, or
- Fail fast with a clear error message listing the incompatible files
BEFORE uploading to CloudFormation.

### Additional Context

1. Create a monorepo project with agentcore config at the root:

my-project/
├── agentcore/
│ ├── agentcore.json (codeLocation: "./")
│ └── cdk/
│ └── node_modules/ (272MB — auto-created by agentcore deploy)
├── infrastructure/ (CDK stacks, Lambda layers with x86_64 binaries)
├── agents/ (actual agent code — 220KB)
├── shared/ (shared utilities — 52KB)
└── tools/ (agent tools — 72KB)

2. Run: agentcore deploy -y

3. The CLI bundles EVERYTHING from codeLocation "./" into the CodeZip artifact,
including agentcore/cdk/node_modules/, agentcore/.cache/, and infrastructure/

4. Deploy fails with:
"Agent runtime creation failed with status: CREATE_FAILED.
Reason: Your artifact contains binary files that are incompatible
with Linux ARM64. Please rebuild your artifact with ARM64-compatible
dependencies."

The x86_64 binaries come from infrastructure/lambda-layer/ which has
nothing to do with the agent code — but gets bundled because there's
no way to exclude directories from codeLocation.

5. Even after removing the incompatible binaries, the artifact exceeds
the 250MB CodeZip limit because agentcore/cdk/node_modules/ (272MB)
and agentcore/.cache/ (1.4GB) are included.

Expected: A way to exclude directories/patterns from the CodeZip bundle.
Workaround: Manually rm -rf agentcore/.cache agentcore/cdk/cdk.out
before every deploy.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.