[All Platforms][Security] dcode startup secret detection returns exit code 0 instead of 2 when refusing to start

[hulynn]

Description

When a raw secret-shaped value (e.g. an API key) is present in
/sandbox/.deepagents/.env, dcode correctly detects it and refuses to
start with the message "dcode: refusing to start — .env contains a
secret-shaped value in OPENAI_API_KEY." However, it returns exit code 0
instead of exit code 2.

This undermines security guardrails — callers checking exit code to
detect secret leaks will miss the rejection.

Platform scope: Reproduced on ubuntu22, ubuntu26-gpu, dgx-station;
other platforms not tested but likely same behavior
(CLI code path is platform-independent).
Regression: Yes — worked in v0.0.73 (exit code 2), broken in v0.0.81
(exit code 0).

Environment

Device:        CI runners (Ubuntu 22.04, Ubuntu 26.04, DGX Station)
OS:            Ubuntu 22.04 / Ubuntu 26.04 / DGX Station
Architecture:  x86_64
Node.js:       v22.23.1
npm:           10.9.2
Docker:        29.x
OpenShell CLI: 0.0.72
NemoClaw:      v0.0.81
OpenClaw:      N/A (dcode agent)

Steps to Reproduce

1. Install NemoClaw v0.0.81
2. Onboard a dcode sandbox: nemoclaw onboard --agent dcode --name test-dcode --non-interactive
3. Write a secret-shaped value to .env:

   nemoclaw test-dcode exec -- bash -c 'echo "OPENAI_API_KEY=sk-live-XXXXXXXXXXXXX" > /sandbox/.deepagents/.env'

4. Run: nemoclaw test-dcode exec -- bash -c 'dcode -n "Reply with PING." 2>&1; echo "EXITCODE:$?"'
5. Observe the exit code

Expected Result

Exit code should be 2 (as observed in v0.0.73 day0 testing).
The rejection message is printed correctly, so the detection logic works
— only the exit code is wrong.

Actual Result

dcode: refusing to start — /sandbox/.deepagents/.env contains a
  secret-shaped value in OPENAI_API_KEY.
  Remove it from the environment, or use 'nemoclaw credentials' to
  register provider keys.
EXITCODE:0

The rejection message is correct but exit code is 0 instead of 2.

Logs

AssertionError: expected 'dcode: refusing to start — /sandbox/...'
  to contain 'EXITCODE:2'
  - Expected: EXITCODE:2
  + Received: dcode: refusing to start — /sandbox/.deepagents/.env
    contains a secret-shaped value in OPENAI_API_KEY.
    Remove it from the environment, or use 'nemoclaw credentials'
    to register provider keys.
    EXITCODE:0

[TonyLuo-NV]

I could not reproduce a lost exit code. Measured every layer on a leased Ubuntu 24.04 x86_64 box against the shipped managed image, and each one returns 2 faithfully. The EXITCODE:0 in the report is produced by the shape of the reproduction command, not by dcode.

The finding

The repro in step 4 is:

nemoclaw test-dcode exec -- bash -c 'dcode -n "Reply with PING." 2>&1; echo "EXITCODE:$?"'

dcode is not the last command in that bash -c — echo is. So the exit status of the whole nemoclaw exec is echo's 0, no matter what dcode returned. The EXITCODE: value that the inner echo prints is correct; the status the outer command returns is always 0.

Both halves, measured on the real image (ghcr.io/nvidia/nemoclaw/langchain-deepagents-code-sandbox:cohort-ghrun-30961904822-1), through the full launcher → session-supervisor → wrapper chain, with a secret planted in .env exactly as in step 3:

$ docker run --rm --entrypoint /bin/bash "$IMG" -c '
    mkdir -p /sandbox/.deepagents
    echo "OPENAI_API_KEY=sk-live-XXXXXXXXXXXXXXXX" > /sandbox/.deepagents/.env
    dcode -n "Reply with PING." >/dev/null 2>&1
  '; echo "DOCKER_RC=$?"
DOCKER_RC=2                       # dcode really does exit 2

$ docker run --rm --entrypoint /bin/bash "$IMG" -c '
    mkdir -p /sandbox/.deepagents
    echo "OPENAI_API_KEY=sk-live-XXXXXXXXXXXXXXXX" > /sandbox/.deepagents/.env
    dcode -n "Reply with PING." 2>&1; echo "EXITCODE:$?"
  '; echo "DOCKER_RC_OF_THAT_RUN=$?"
  Remove it from the environment, or use 'nemoclaw credentials' to register provider keys.
EXITCODE:2                        # inner echo prints the right value
DOCKER_RC_OF_THAT_RUN=0           # the run's own status is echo's

So the refusal exits 2 as designed, and the trailing echo is what yields 0.

Layers ruled out

Each measured independently, none loses a code.

OpenShell exec transport (0.0.85), against a live sandbox:

exit 0 → HOST_RC=0    exit 42       → HOST_RC=42
exit 1 → HOST_RC=1    stderr+exit 2 → HOST_RC=2
exit 2 → HOST_RC=2    exec failure  → HOST_RC=126

Byte-faithful, including the stderr-plus-nonzero shape this issue is about. This also retires the theory I raised on PR #8206 that the v0.0.73→v0.0.81 regression window lines up with the OpenShell pin moving 0.0.71→0.0.72 — the transport is not at fault.

Session supervisor on real Linux, where the sys.platform guard previously blocked testing, including the subreaper and orphaned-grandchild paths that a LangGraph server would create:

child exits 2                → supervisor_rc=2
child exits 1                → supervisor_rc=1
child spawns orphan, exits 2 → supervisor_rc=2
child killed by SIGKILL      → supervisor_rc=137

Wrapper through OpenShell exec, and a control in the same sandbox:

openshell sandbox exec -- /usr/local/lib/nemoclaw/dcode-wrapper.sh -n ""  → HOST_RC=2
openshell sandbox exec -- /bin/sh -c 'exit 2'                             → HOST_RC=2

One more trap worth knowing

openshell sandbox exec inherits and consumes stdin. My first two probe scripts were piped in over stdin and the exec silently ate the remainder, so the run looked like it stopped after one line. If the QA harness feeds commands over a pipe, this can truncate or reorder what it captures — which may also explain 8138's inverted output ordering, where EXITCODE:0 is printed before the error message it supposedly follows.

What I need to close this

The measurements say the product is correct and the harness reads the wrong status. To confirm rather than assume, could you share the exact harness code around step 4 — specifically whether the asserted value is the inner echo output or the outer $?? If it is the outer $?, the fix is in the check:

# returns dcode's status
nemoclaw test-dcode exec -- bash -c 'dcode -n "Reply with PING." >/dev/null 2>&1'; echo "EXITCODE:$?"

Caveats on my run, stated so they can be checked: the sandbox was created directly with openshell sandbox create rather than by nemoclaw onboard, because I had no inference credential. In that sandbox dcode itself stops at 126 (/opt/venv/bin/python3: Permission denied) under landlock, which is an artifact of the missing onboard-time policy, not of this issue — so the end-to-end -n run through OpenShell was measured with the wrapper and with controls rather than with dcode itself. The full launcher → supervisor → wrapper chain was measured in plain Docker, where it returns 2.