[BUG] AgentCore Harness: environmentVariables stored in resource config are not injected into microVM process env

Describe the bug

environmentVariables set on aws_bedrockagentcore_harness (or via CreateHarness / UpdateHarness API directly) are stored and returned by GetHarness and GetAgentRuntime, but are not injected into the microVM's process environment — PID 1's /proc/1/environ and every subprocess spawned by the shell tool / skill scripts show them as absent.

Per AWS docs — Environment variables:

Set environment variables that are passed to the runtime container. Environment variables are available to the agent and any custom container running in the session.

And Custom environment (container images):

The harness overrides your container's ENTRYPOINT and CMD to keep it running as an environment. Your installed software, filesystem, and environment variables are available to the agent; your container's startup command is not executed.

Neither is true empirically today — the env vars are stored in the harness / runtime resource metadata but never reach the running container process.

To Reproduce

1. Set any custom environmentVariables on a harness — via terraform, the SDK, or CLI. Example CLI:

   aws bedrock-agentcore-control update-harness \
     --harness-id <id> \
     --region <region> \
     --environment-variables '{"FOO": "bar"}'
   

2. Confirm the control plane accepted the write:

   aws bedrock-agentcore-control get-harness \
     --harness-id <id> --region <region> \
     --query 'harness.environmentVariables' --output json
   # → {"FOO": "bar"}
   
   aws bedrock-agentcore-control get-agent-runtime \
     --agent-runtime-id <auto-created-runtime-id> \
     --region <region> \
     --query 'environmentVariables' --output json
   # → {"FOO": "bar", "AWS_REGION": "...", "AWS_STAGE": "prod",
   #    "AWS_MEMORY_ARN": "...", "AWS_CUSTOMER_CONTAINER_URI": "...",
   #    "AWS_TRUNCATION_STRATEGY": "sliding_window",
   #    "AWS_TRUNCATION_MESSAGES_COUNT": "150"}
   

3. Invoke the harness with any prompt that triggers a shell tool call, and enumerate the container process env directly (not via the shell tool's own subprocess — read /proc/1/environ to bypass subprocess-env-reset concerns):

   shell> cat /proc/1/environ | tr '\0' '\n' | sort
   # → PATH=/usr/local/bin:...
   # → LANG=C.UTF-8
   # → GPG_KEY=...
   # → PYTHON_VERSION=3.12.14
   # → PYTHON_SHA256=...
   # → HOSTNAME=localhost
   # → HOME=/root
   #
   # NEITHER FOO nor any of the AWS_* system-injected vars appear.
   

   printenv FOO from the shell tool returns exit code 1 and empty stdout. The pattern is identical for the AWS_* system vars — printenv AWS_REGION also returns nothing, even though get-agent-runtime shows AgentCore has populated it.

Expected behavior

Per the linked docs, both:

• User-set environmentVariables (e.g. FOO=bar), AND
• AWS-injected system env vars (AWS_REGION, AWS_STAGE, AWS_MEMORY_ARN, AWS_CUSTOMER_CONTAINER_URI, AWS_TRUNCATION_*)

should appear in /proc/1/environ and in every subprocess spawned inside the microVM.

Actual behavior

Only the base container image's own env vars — from Dockerfile ENV lines and Python base image defaults — are visible. Zero of the AgentCore-set environmentVariables reach the process, including the AWS_* system vars the runtime itself claims to inject. PID 1 is a bare sh from the Docker base image, not something wrapping / exporting the AgentCore-provided env.

Interim workaround

Bake env vars directly into the container image as ENV lines. Docker ENV becomes part of the image and is inherited by the process regardless of AgentCore's runtime injection layer:

FROM public.ecr.aws/docker/library/python:3.12-slim
ENV FOO=bar
ENV AWS_REGION=ap-southeast-1
# ...

This confirms the container itself accepts env vars fine, so the issue is in AgentCore's runtime start / env-injection layer, not the container image or the terraform provider.

Trade-off: image becomes environment-specific (staging vs production must be separate images), which defeats the design intent of runtime-injected env vars — the whole point of the API's environmentVariables field is to let one image serve every environment.

Environment

• Region: ap-southeast-1
• Model: global.anthropic.claude-sonnet-4-6 (Bedrock, converse_stream)
• Runtime networkMode: VPC
• Custom container image: python:3.12-slim base, linux/arm64, ENTRYPOINT/CMD unset (per docs — AgentCore overrides them)
• Runtime version: (from service.instance.id in OTel resource — AgentCore-managed, no user control)

Impact

Blocks the intended env-var-driven configuration pattern (per-env values for API tokens, table IDs, feature flags, etc.). Every env-var-consuming skill script — boto3 clients reading AWS_REGION, framework code reading AWS_STAGE, application code reading LARK_BASE_APP_TOKEN / LARK_APPROVAL_CODE / etc. — falls back to hardcoded defaults or fails outright.

Additional context

Repro is deterministic — happens on every new session against any harness that has environmentVariables set. Docker ENV workaround (baked at image build time) proves the container process accepts env vars; the missing layer is AgentCore's runtime start / injection. Even the system-injected AWS_* vars listed in get-agent-runtime don't reach PID 1, so this isn't a "user config not honored" edge case — it's a general failure of the injection step.

Related: aws_bedrockagentcore_harness terraform provider correctly wires the environment_variables field to the AWS API; the value round-trips through the control plane state cleanly. The gap is strictly service-side (runtime container start).

Không xác định được tệp repository hoặc bài kiểm thử nào; báo cáo quy khoảng thiếu sót này cho lớp khởi động runtime và tiêm biến môi trường phía dịch vụ AgentCore. Hãy tái hiện bằng AWS CLI, sau đó kiểm tra /proc/1/environ và đầu ra của tiến trình con; được xem là hoàn tất khi các biến của người dùng và các biến do AWS tiêm vào xuất hiện trong môi trường tiến trình của microVM, thay vì yêu cầu các mục ENV trong Dockerfile.