bug: sandbox --env is not passed to the initial command

[kaofelix]

User Story

As an OpenShell user launching an application in a sandbox, I want values
supplied with sandbox create --env to be available to the initial command, so
that the application starts with its requested configuration.

Problem Statement

OpenShell 0.0.117-dev.155+gb3e4ad457 accepts
--env REPRO_SENTINEL=present, but the initial sandbox command observes the
variable as unset.

The same reproduction reports present on OpenShell v0.0.116.

Impact / Why This Matters

Applications launched as the sandbox's initial command can start without
required configuration. Later exec sessions may still observe the configured
environment, which can make the sandbox appear correctly configured during
diagnosis.

This affected an OpenClaw hosted-inference validation for
NVIDIA/NemoClaw#11810.

Current workarounds are to remain on OpenShell v0.0.116 or change the
application image or launch command to supply the configuration another way.

Acceptance Criteria

• The initial command receives values supplied through
  sandbox create --env.
• The initial command and later sandbox exec sessions observe the same
  configured environment.
• A Docker-backed regression test covers this behavior.
• The reproduction below prints observed=present.

Reproduction Steps

Run against a healthy gateway using OpenShell
0.0.117-dev.155+gb3e4ad457:

openshell sandbox create \
  --name env-repro \
  --from ghcr.io/nvidia/openshell-community/sandboxes/base@sha256:aeef1c63f00e2913ea002ccb3aaf925f338b5c5d70e63576f0d95c16a138044e \
  --env REPRO_SENTINEL=present \
  --detach \
  --no-tty \
  --no-auto-providers \
  -- /bin/sh -c 'printf "%s\n" "${REPRO_SENTINEL:-missing}" > /sandbox/env-result; sleep 300'

printf 'observed='
openshell sandbox exec \
  --name env-repro \
  --no-tty \
  --no-login-shell \
  -- /bin/cat /sandbox/env-result

openshell sandbox delete env-repro

Expected:

observed=present

Actual:

observed=missing

No credentials or external inference endpoints are required.

Environment

• OpenShell: 0.0.117-dev.155+gb3e4ad457
• Revision: b3e4ad4579e24dacfb285924876473b50a04b988
• Artifacts:
  Release Dev run 35055785361
• Host: macOS 26.5.2, Apple Silicon
• Runtime: Docker Desktop
• Docker client/server: 29.8.0
• Docker VM: Linux ARM64, LinuxKit 7.0.12
• Sandbox image:
  ghcr.io/nvidia/openshell-community/sandboxes/base@sha256:aeef1c63f00e2913ea002ccb3aaf925f338b5c5d70e63576f0d95c16a138044e

The same failure was reproduced on a separate Linux ARM64 Docker host.

Control result:

• OpenShell v0.0.116 with the same sandbox create command and its supported
  sandbox exec syntax: observed=present

Logs

Created sandbox: env-repro

[0.0s] Requesting compute...
[0.0s] Sandbox allocated
[0.0s] Image already present
[0.1s] Starting sandbox Container created
observed=missing

[cv]

We reproduced this in NemoClaw on Linux ARM64 with OpenShell b3e4ad4579e24dacfb285924876473b50a04b988. The initial process exited before harness initialization with KeyError: 'NEMOCLAW_AGENT_NAME', even though the variable was present in the declared sandbox environment.

Findings

At that revision, apply_canonical_process_environment in crates/openshell-sandbox/src/process.rs receives the declared user environment, but only consults it when deciding whether to supply defaults for HOME, USER, SHELL, and TERM. It never applies the declared map to the child command.

The RFC 0012 runtime split (#2942) deliberately moved workload environment configuration out of the supervisor's inherited environment. The Docker driver documentation says the configuration is carried through the protected bootstrap and exposed to workload children, while supervisor-owned variables remain protected. The missing application to the initial child appears to be an incomplete handoff, rather than an intentional removal of --env support.

We also checked main at 2ccef97769e0e39c4dc06b4c3953d3735814f146: the affected process.rs is unchanged from b3e4ad457. This is a source comparison, not a fresh live reproduction against that revision.

Suggested minimal patch

Apply the declared map at the start of apply_canonical_process_environment:

cmd.envs(user_environment);

At both initial-process launch call sites, move the existing stripping and provider injection steps after the canonical environment application:

apply_canonical_process_environment(
    &mut cmd,
    policy,
    workspace,
    interactive,
    &configured_user_environment(),
);
strip_supervisor_only_env(&mut cmd);
inject_provider_env(&mut cmd, provider_env);

This is one added line and two reorderings in the same file. The ordering matters: adding only cmd.envs(...) at the current location would allow declared values to overwrite the earlier environment sanitization and provider-placeholder injection. The proposal preserves those protections and does not restore broad supervisor-environment inheritance.

Regression coverage

The suggested change passed a child-process regression test in both interactive and non-interactive modes, verifying that:

• Declared application variables and an explicit HOME reach the child.
• Supervisor-only sandbox tokens are removed.
• Provider credential placeholders override caller-supplied values for the same keys.

The sandbox library suite passed with 201 tests and one explicit skip.

The remaining check is the Docker-backed reproduction in this issue: rebuild the runtime artifacts, verify that the initial command prints observed=present, and confirm that a later exec session receives the same declared environment. That end-to-end check has not yet been run with the suggested change.