harness: `dockerfile` field in harness.json is silently ignored on deploy (no image is built or pushed)

[aryankhanna2004]

Summary

On the preview branch, harness.json validates the dockerfile field (see src/schema/schemas/primitives/harness.ts / src/schema/llm-compacted/agentcore.ts), and agentcore create / agentcore add harness with a template will copy a Dockerfile next to harness.json. However, agentcore deploy does not build or push the Dockerfile, and no error/warning is emitted. The resulting harness is created without any custom container — silently.

This is surprising given the obvious user expectation that setting dockerfile: "Dockerfile" in harness.json would cause the CLI to build/push that image (mirroring the agent Container build path introduced in #783).

Version / Environment

• @aws/agentcore@1.0.0-preview.1 (installed globally and verified by building and running HEAD of the preview branch locally)
• macOS 15.3 / Node 20 / Docker available
• Region: us-east-1

Reproduction

harness.json:

{
  "name": "pptagent",
  "model": { "provider": "bedrock", "modelId": "us.anthropic.claude-opus-4-5-20251101-v1:0" },
  "tools": [
    { "type": "agentcore_browser", "name": "browser" },
    { "type": "agentcore_code_interpreter", "name": "code-interpreter" }
  ],
  "skills": ["/opt/skills/pptx"],
  "dockerfile": "Dockerfile",
  "sessionStoragePath": "/mnt/data",
  "authorizerType": "AWS_IAM"
}

A Dockerfile exists alongside harness.json. Running:

agentcore deploy --yes --verbose

completes successfully, but:

1. No Docker build or ECR push step runs.
2. The synthesized CFN template (agentcore/cdk/cdk.out/*.template.json) contains no container image / ECR / asset references for the harness.
3. The resulting harness has no custom environment artifact.

Root cause (code pointers on preview)

src/cli/operations/deploy/imperative/deployers/harness-mapper.ts only consumes containerUri when building CreateHarness options:

// Container artifact
if (harnessSpec.containerUri) {
  result.environmentArtifact = mapEnvironmentArtifact(harnessSpec.containerUri);
}

The dockerfile field from the validated HarnessSpec is never read by the deployer. src/assets/cdk/bin/cdk.ts does pass hasDockerfile: !!harnessSpec.dockerfile into the CDK stack, but the CDK construct (AgentCoreHarnessRole) only creates an IAM role; there is no DockerImageAsset / CodeBuild step that produces a containerUri for harnesses. As a result, dockerfile is declared-but-unimplemented.

Expected behavior

Either:

• (A) Implement build+push — When harnessSpec.dockerfile is set and harnessSpec.containerUri is not, build the Dockerfile next to harness.json and push it (via CDK DockerImageAsset or a CodeBuild-backed asset, mirroring the agent Container path), then feed the resulting image URI into mapHarnessSpecToCreateOptions.
• (B) Minimum bug fix — Until (A) ships, fail fast with a clear, actionable error during agentcore deploy instead of silently ignoring dockerfile.

I'm happy to send a PR for (B) (fail fast + unit test) immediately, and would love guidance on (A) if it's already on the roadmap.

Related

• feat: add custom dockerfile support for Container agent builds #783 added custom Dockerfile support for Container agents — the harness path appears to have been overlooked.
• [DO NOT MERGE] Feat/harness implementation #909 (closed) contained early harness implementation.

[aryankhanna2004]

Update: #929 (by @tejaskash) landed a few minutes before my PR #930. After reading both diffs side-by-side I think #929 is the better fix and I'm closing #930 in its favor.

Both PRs make the same changes in bin/cdk.ts and harness-mapper.ts; they diverge only on how the image is built.

Dimension	#929 (recommended)	#930 (mine)
CDK construct	ContainerSourceAssetFromPath + AgentEcrRepository + ContainerBuildProject + ContainerImageBuilder from @aws/agentcore-cdk	DockerImageAsset from aws-cdk-lib/aws-ecr-assets
Build runs in	AWS CodeBuild (cloud-side)	Local Docker daemon
Local prereqs	None	docker + buildx with linux/arm64
arm64	Native CodeBuild arm64 pool	QEMU cross-compile on x86 hosts
ECR repo	Per-harness named repo, lifecycle per harness	Shared CDK bootstrap asset bucket
Preflight	validateHarnessDockerfiles() — fails synth with a clear error + unit tests	None
Consistency with existing agent Container path	Mirrors it exactly	Introduces a different primitive

Two main reasons #929 is better:

1. It reuses the Container-agent pipeline that's already in the CLI, so harnesses and agents stay on one build path instead of two.
2. It doesn't require a local Docker daemon — the CLI keeps working in CI/Cloud9/WSL, and arm64 builds happen natively on CodeBuild instead of via QEMU.

Not blocking this issue or #929 on it, but while testing the build+push fix end-to-end I hit a separate service-side bug where customer-env ctr run fails with exit 1 for any non-default environmentArtifact.containerConfiguration.containerUri (reproducible with the stock public.ecr.aws/docker/library/python:3.12-slim-bookworm from the docs). Filed as #931.

[tejaskash]

Hi @aryankhanna2004 Thank you for sending #930 . After discussing internally we decided it was best to reuse Docker building code we have in @aws/agentcore-cdk which is why I sent out a PR after testing the fix locally. Thank you for catching this bug and we welcome future contributions!