[DGX Spark][CLI&UX] nemoclaw exec always returns 0 — swallows the remote command's non-zero exit codes

[hulynn]

Description

nemoclaw {sandbox} exec -- {cmd} always exits 0 on the host regardless
of what {cmd} exits with inside the sandbox. The CLI's own --help text
explicitly documents:

"exits with the remote command's exit code"

but the host-side return value is always 0, even when the inner command
exits 42 or 1. This breaks any host-side scripting or automation that
depends on exec signalling non-zero when the remote command fails.

Platform scope: Reproduced on DGX Spark only; other platforms not tested.
Regression: Unknown — earlier versions not tested.

Environment

Device:        DGX Spark (aarch64)
OS:            Linux 6.11.0-1014-nvidia
Architecture:  aarch64
Node.js:       v22.22.3
npm:           10.9.8
Docker:        Docker Engine 28.3.3
OpenShell CLI: openshell 0.0.72
NemoClaw:      v0.0.76
OpenClaw:      2026.6.10 (aa69b12)

Steps to Reproduce

1. Onboard a fresh sandbox on DGX Spark:
     nemoclaw onboard --yes --non-interactive --fresh --agent openclaw --name exec-probe
2. Run a command that exits 42 and observe the host-side exit code:
     nemoclaw exec-probe exec -- sh -c 'exit 42'
     echo "host saw: $?"
3. Run a command that exits 1 and observe the host-side exit code:
     nemoclaw exec-probe exec -- sh -c 'exit 1'
     echo "host saw: $?"

Expected Result

• Step 2 host prints: host saw: 42
• Step 3 host prints: host saw: 1
• Matches the documented behaviour ("exits with the remote command's
  exit code") from nemoclaw exec --help.

Actual Result

• Step 2 host prints: host saw: 0 (expected 42)
• Step 3 host prints: host saw: 0 (expected 1)

Reproduced on a fresh, healthy sandbox with baseline sanity: steps like
nemoclaw exec-probe exec -- echo hello,
nemoclaw exec-probe exec -- whoami, and
nemoclaw exec-probe exec -- sh -c 'echo $HOME' all succeed and
print their real stdout on the host. Only the exit code is being
swallowed by the exec wrapper.

Logs

`nemoclaw exec --help` (self-contradictory — docs promise propagation):

    DESCRIPTION
      Run a command non-interactively in a running sandbox

      Run a single command inside a running sandbox via the OpenShell exec
      endpoint. The command runs as the sandbox user (HOME=/sandbox) and
      exits with the remote command's exit code. Use `--` to separate exec
      options from the user command.

Host-side console evidence from a fresh sandbox `exec-probe`:

    === Step8: exec exit 42 (propagation) ===
    [step8] exit=0 elapsed=1214ms (expect 42)

    === Step9: exec exit 1 ===
    [step9] exit=0 elapsed=1167ms (expect 1)

The inner commands run to completion (elapsed ~1.2s, matching a real
shell round-trip inside the sandbox); only the return path from the
exec wrapper is broken.

[Hokonoken]

Traced the full exec exit-code path through both repos (NemoClaw main be3e7cc8f and the v0.0.76 tag you run; OpenShell main f7aa3aa3 and the v0.0.72 tag), and reproduced the propagation end-to-end locally. Short version: I can't get nemoclaw exec itself to swallow the exit code — every layer forwards it, there's already a unit test asserting it, and an isolated end-to-end run on my machine propagates 42/1/7/137 faithfully. That points at the measurement path rather than exec. Details and a one-line discriminating test below.

The propagation chain is intact at every layer

1. NemoClaw command → action. src/commands/sandbox/exec.ts calls execSandbox, whose last statement is process.exit(completion.code) (src/lib/actions/sandbox/exec.ts). completion.code is cleanupError ? 1 : commandCode.
2. NemoClaw exit computation. commandCode = computeExitCode(result).code = spawnExitCode(result), which returns result.status — the exit code of the openshell child process (src/lib/core/process-exit.ts). A signal maps to 128+n, never 0.
3. NemoClaw runtime-env wrapper. The command is wrapped as /bin/bash --noprofile --norc -p -c '…; builtin exec -- "$@"' nemoclaw-runtime-env <cmd…> (src/lib/actions/sandbox/runtime-env.ts). exec replaces bash with the command, so the wrapper's exit code is the command's. Verified by hand: the wrapper returns 42 for sh -c 'exit 42', with and without the env file present.
4. OpenShell CLI. SandboxCommands::Exec calls sandbox_exec_grpc(...) and then if exit_code != 0 { std::process::exit(exit_code); } (crates/openshell-cli/src/main.rs, identical in v0.0.72).
5. OpenShell server. The exec loop captures the SSH ChannelMsg::ExitStatus and sends it as ExecSandboxExit { exit_code } (crates/openshell-server/src/grpc/sandbox.rs run_exec_with_russh / stream_exec_over_relay). If the exit-status is lost, exec_loop_result returns Err(unavailable) which is forwarded as tx.send(Err(...)) → the CLI sees a stream error and exits non-zero. It does not silently become 0.
6. OpenShell supervisor. Both the PTY and pipe exec paths compute status.and_then(|s| s.code()).unwrap_or(1) and send it via exit_status_request(channel, code) (crates/openshell-supervisor-process/src/ssh.rs). Signal death → 1, never 0.

Existing coverage + local reproduction

• There's already a passing unit test asserting propagation: src/lib/actions/sandbox/exec.test.ts — computeExitCode({ status: 42 }) ⇒ { code: 42 }, and "preserves the command exit code on a denied failure" drives the full execSandbox and asserts exitCode is 56.

• I ran the real execSandbox end-to-end against a stub openshell that runs the wrapped command and returns its code (a real subprocess spawn, real bash runtime-env wrapper, non-TTY stdin like a script):

  inner exited 42  -> nemoclaw host saw: 42
  inner exited 1   -> nemoclaw host saw: 1
  inner exited 7   -> nemoclaw host saw: 7
  inner exited 0   -> nemoclaw host saw: 0
  inner exited 137 -> nemoclaw host saw: 137
  

So nemoclaw exec's own exit path is faithful on these versions.

What I could not verify — and a discriminating test

The one thing I can't exercise without DGX Spark hardware is the live gateway's real SSH round-trip. But the server code either delivers the real ExitStatus or forwards an error (non-zero) — I found no path that yields a clean exit 0 for a command that exited non-zero.

Your evidence is from a harness ([step8] exit=0 elapsed=1214ms). The most likely place the code is being lost is between nemoclaw exec and that exit= capture. Could you run the bare command directly in a shell, with nothing in between, and paste the raw $?:

nemoclaw exec-probe exec -- sh -c 'exit 42'; echo "raw host exit: $?"

• If that prints raw host exit: 42, the swallow is in the Step8/Step9 wrapper (e.g. a pipe into tee/logging without set -o pipefail, or a wrapper reporting its own status) — happy to help pinpoint it if you share how Step8 invokes and captures the command.
• If it prints raw host exit: 0, then it's a live-gateway behavior my isolated harness can't see, and the DGX Spark openshell sandbox exec gRPC exit event is the place to look — I'd then want openshell sandbox exec --name exec-probe -- sh -c 'exit 42'; echo $? (bypassing NemoClaw) to localize it to OpenShell.

One latent hardening note (not the observed bug)

sandbox_exec_grpc initializes let mut exit_code = 0i32; and only overwrites it on an Exit event (crates/openshell-cli/src/run.rs). Today the server guarantees an Exit event or a stream error, so this is safe. But as defense in depth it would be more robust to track whether an Exit event was seen and treat "clean stream close with no exit status" as an error rather than success — mirroring the server's own exec_loop_result. Flagging in case it's useful; it does not explain the current report on its own.

Happy to dig further once the bare-command $? is known.

[Hokonoken]

Confirmed on a real sandbox now (not just the isolated harness above): stood up OpenShell 0.0.72 + a live hermes sandbox and ran nemoclaw <name> exec -- sh -c 'exit N' for several codes:

inner exit 42  -> host saw: 42
inner exit 1   -> host saw: 1
inner exit 0   -> host saw: 0
inner exit 7   -> host saw: 7
inner exit 137 -> host saw: 137

stdout also flows (echo hello → hello, exit 0), matching your baseline sanity note. So end-to-end through a real OpenShell exec — not a stub — the exit code propagates faithfully on x86_64. That leaves the DGX Spark (aarch64) path or the measurement wrapper as the remaining variable; the bare-command $? I asked about above is still the quickest way to tell which.

[Thabhelo]

Hi, I'd like to pick this up if no one is already on it. I fixed similar exit-code propagation in #5029 / #5044, so this looks like a good fit for me. Is anyone already working on exec exit codes, or is it OK to claim?

[Thabhelo]

I will be taking this on. No competing PR found; opening a fix with oclif exit-code hardening and CLI integration tests for remote exit propagation.

[sandl99]

Closing as not reproducible on DGX Spark after direct retest. Tested both latest 0.0.79 and 0.0.76 with bare nemoclaw tm exec checks. Exit 42 returned host 42, and exit 1 returned host 1. This matches the documented contract and points to the original exit equals 0 evidence coming from the surrounding harness or capture path rather than nemoclaw exec itself.