SANDBOX_FLAGS --env silently wipes the app service environment in Airlock mode

[GordonBeeming]

SandboxFlags.ToComposeYaml() emits its own environment: mapping for every --env flag, but docker-compose.airlock.yml.template already sets environment: on the app service. The generated Compose file ends up carrying that key twice on the same service, and the later one wins.

Everything the template put there is dropped: HTTP_PROXY, HTTPS_PROXY, http_proxy, https_proxy, PUID, PGID, the auth env vars, the Docker broker env, TERM and COPILOT_HERE_SESSION_INFO. Nothing errors, so it fails quietly.

Repro

SANDBOX_FLAGS="--env DEBUG=1" copilot_here --enable-airlock

Parsing the shape the generated file ends up with:

>>> yaml.safe_load(doc)["services"]["app"]["environment"]
['DEBUG=1']

The proxy and PUID/PGID entries are gone.

Where

• app/Infrastructure/SandboxFlags.cs:71 — the --env branch guards against emitting environment: twice within its own output, but has no idea the template already declared it.
• app/Resources/docker-compose.airlock.yml.template:41 — the app service's environment: block.
• {{EXTRA_SANDBOX_FLAGS}} substitutes in at line 58, well after that block.

Scope

Only environment: collides. cap_add, cap_drop, ulimits, mem_limit and cpus aren't in the template, so those pass through fine. Non-airlock runs are unaffected, since they pass -e straight to docker run.

Suggested fix

Inject --env values into the template's existing environment: list through a placeholder of their own, next to {{AUTH_ENV_VARS}}, and leave the remaining flags on {{EXTRA_SANDBOX_FLAGS}}.

Codex spotted this while reviewing #132, which adds another documented --env example. The bug predates that PR and isn't introduced by it.