[macOS] SSH handshake verification fails after Docker container restart — sandbox requires destroy/recreate

[JohnWilky]

Description

Environment: macOS Apple Silicon (Mac Mini), Docker Desktop 29.2.1, OpenShell 0.0.13, NemoClaw 0.1.0, OpenClaw 2026.3.11
What happens: After any Mac reboot or docker restart openshell-cluster-nemoclaw, the sandbox shows Phase: Ready but all SSH connections fail with SSH connection: handshake verification failed in a loop. nemoclaw connect returns exit 255. The Telegram bridge reports "Agent exited with code 255" or "code null."
Logs show: Gateway repeatedly connects TCP, sends NSSH1 handshake, receives response, but sandbox rejects with "handshake verification failed" — every 2 minutes indefinitely.
Only workaround: nemoclaw destroy --yes followed by full reinstall via curl -fsSL https://nvidia.com/nemoclaw.sh | bash. No lesser fix works — the SSH keys appear to get out of sync between gateway and sandbox when the container restarts.
Impact: Makes NemoClaw unusable as an always-on agent on macOS since any reboot requires a full 10-minute reinstall cycle.
Related: #260 (macOS tracking), #311 (gateway restart after reboot)

Reproduction Steps

Steps to reproduce:

Install NemoClaw on macOS Apple Silicon via curl -fsSL https://nvidia.com/nemoclaw.sh | bash
Complete onboard (NVIDIA Cloud API, any model, any sandbox name)
Verify sandbox works: nemoclaw connect → success
Reboot the Mac (or run docker restart openshell-cluster-nemoclaw)
Wait for Docker and container to fully start (docker ps shows healthy)
Run nemoclaw connect → fails with exit 255
Run nemoclaw logs --follow → shows SSH connection: handshake verification failed repeating

Expected: Sandbox reconnects after container restart.
Actual: SSH handshake permanently broken. Only destroy --yes + full reinstall resolves it.

Environment

Environment:

macOS 26.3.1
Mac Mini, Apple Silicon
Docker Desktop 29.2.1
OpenShell 0.0.13
NemoClaw 0.1.0
OpenClaw 2026.3.11 (29dc654)
Node.js v22.22.1
npm 10.9.4
Homebrew 5.1.0

Debug Output

Logs

Checklist

• I confirmed this bug is reproducible
• I searched existing issues and this is not a duplicate

[wscurran]

✨ Thanks for submitting this issue with a detailed description, it addresses a bug that could cause issues with the SSH connection, which could improve the reliability of NemoClaw on MacOS.

---

Possibly related open PRs:
#838 docs: improve macOS install guidance for Xcode and container runtimes (#814),
#819 feat: add Podman as supported container runtime for macOS and Linux,
#635 fix(docker): set nemoclaw-start permissions to 755 for sandbox readability (fixes #622)

[ibytergj]

I cannot understand why nobody is giving this any attention. The only work around is to recreate your sandbox every time reboot. This is a problem on Linux as well. It's not specific to the Mac.

[rafaelluna]

Agreed! I've been having this same issue every time but also on Windows with Ubuntu WSL

[Chutengli]

Getting the same issue with Mac

[jtahaney]

Experiencing the same issue on Ubuntu 22.04.5 LTS.

[Chutengli]

Hi, I do think issue needs attention. This is definately a major one

[goodgoodgolden-stack]

Environment:

Device: NVIDIA DGX Spark GB10
OS: Ubuntu 24.04 (aarch64)
Docker: 28.x
OpenShell: 0.0.16
NemoClaw: latest
OpenClaw: 2026.3.11
Node.js: v22.22.1
Inference: Ollama (local), model: nemotron-cascade-2:latest

Issue:
This is the same bug as #768, but reproduced on DGX Spark GB10 (Linux/aarch64), confirming it is cross-platform and not macOS-specific.
After rebooting the Spark, the openshell-cluster-nemoclaw Docker container restarts automatically (configured with --restart always), shows as healthy, and the sandbox shows Phase: Ready — but all SSH connections fail with SSH connection: handshake verification failed in a loop. nemoclaw connect exits silently with code 255.
Logs (nemoclaw my-assistant logs):
SSH tunnel: handshake response received
SSH connection: handshake verification failed peer=10.42.0.17:xxxxx
This repeats indefinitely every ~5 seconds.
Impact:
The mTLS certificates appear to go out of sync between the gateway and sandbox after container restart. There is no way to reconnect without destroying and recreating the sandbox, which also permanently deletes all workspace data (SOUL.md, MEMORY.md, USER.md, etc.) stored in the sandbox PVC.
This makes NemoClaw completely unusable as an always-on agent on DGX Spark, since any reboot requires a full reinstall and loss of all agent memory and personality configuration.
Requested fix:
Please provide a way to resync the mTLS certificates between gateway and sandbox without destroying the sandbox, or persist the certificates across gateway restarts so workspace data is not lost on reboot.

[dknos]

Same issue on WSL2 — fix is to always regenerate SSH config fresh

Confirmed this on WSL2 + Docker Desktop. After any Docker container restart or computer reboot, SSH handshake fails because the gateway rotates its TLS certificates (see #888).

The fix: never cache openshell sandbox ssh-config output. Regenerate it fresh on every SSH call:

SSH_CONF=$(mktemp /tmp/nemoclaw-XXXXXX.conf)
openshell sandbox ssh-config "$SANDBOX" > "$SSH_CONF"
ssh -T -F "$SSH_CONF" "openshell-${SANDBOX}" "your-command"
rm -f "$SSH_CONF"

Since the ssh-config reflects the current certs after gateway restart, using a fresh config on every connection means cert rotation is transparent. We call this pattern in our startup script and every bridge connection — zero destroy/recreate cycles needed.

If openshell sandbox ssh-config itself fails (returns empty), the gateway isn't ready yet — retry with backoff rather than destroying the sandbox.

[Chutengli]

Same issue on WSL2 — fix is to always regenerate SSH config fresh

Confirmed this on WSL2 + Docker Desktop. After any Docker container restart or computer reboot, SSH handshake fails because the gateway rotates its TLS certificates (see #888).

The fix: never cache openshell sandbox ssh-config output. Regenerate it fresh on every SSH call:

SSH_CONF=$(mktemp /tmp/nemoclaw-XXXXXX.conf)
openshell sandbox ssh-config "$SANDBOX" > "$SSH_CONF"
ssh -T -F "$SSH_CONF" "openshell-${SANDBOX}" "your-command"
rm -f "$SSH_CONF"
Since the ssh-config reflects the current certs after gateway restart, using a fresh config on every connection means cert rotation is transparent. We call this pattern in our startup script and every bridge connection — zero destroy/recreate cycles needed.

If openshell sandbox ssh-config itself fails (returns empty), the gateway isn't ready yet — retry with backoff rather than destroying the sandbox.

No, it didn't work for me. I guess it's because openshell cached the certs somewhere else?