sandbox doesn't run the initial custom command after system restart

[ninja18]

Agent Diagnostic

• Docker driver overrides the image ENTRYPOINT with the supervisor binary and hardcodes its command to sleep
  infinity (crates/openshell-driver-docker/src/lib.rs:1759-1762, :1669-1671).
• Workload passed via openshell sandbox create ... -- /app/entrypoint.sh is not stored in the sandbox spec; CLI
  runs it as a one-shot SSH exec session after the sandbox is Ready (crates/openshell-cli/src/run.rs:2169,
  ssh.rs:399).
• On gateway restart after reboot, resume_persisted_sandboxes() (crates/openshell-server/src/lib.rs:344) resumes
  the container via a bare docker start (driver-docker/src/lib.rs:719,738), re-running only PID 1 (supervisor →
  sleep infinity).
• The original -- exec command is never persisted or replayed, so the workload does not return.
• ps aux confirms: first run shows bash /app/entrypoint.sh + openclaw; after restart only sleep infinity remains.
• Net: any command given to sandbox create is ephemeral to the CLI process and lost across gateway/host restarts,
  even though the sandbox reports Ready/Running.

Description

Disclaimer: This could be a bug or feature request or a documentation update for proper usage.

I created a sandbox using my Dockerfile

openshell sandbox create \
 --from "$INSTALL_DIR" \
 --name "$SANDBOX_NAME" \
 --provider "$PROVIDER_NAME" \
 --policy "$POLICY_FILE" \
 --no-tty \
 --no-auto-providers \
 --forward "$GATEWAY_PORT" \
 -- /app/entrypoint.sh

I gave the my entrypoint.sh here because openshell defaults to the supervisor as the container's entrypoint. This script is run on the first run. But after the system restarts and the sandbox is relaunched. This command /app/entrypoint.sh is not run.
Openshell treats the command passed during sandbox creation as one off session command. But I want it to persist this and run it on every restart.

Workaround:
I can create a systemd service and do openshell sandbox exec sandbox_name--no-tty -- /app/entrypoint.sh once the gateway and sandbox is ready on system restart. I was anyway planning to do this because the port forward passed in openshell sandbox create command is also not coming up after system restart.

The ps aux results before and after restart confirm that the command is not run
ps aux results on first run:

ps aux after system restart:

I don't know if this is intentional but while creating a custom sandbox, the sandbox is not useful if the user's entrypoint is not run when the sandbox restarts. Also I couldn't find any documentation saying that the command passed during sandbox creation is temporary.

Reproduction Steps

1. Run sandbox from custom image with a entrypoint command

openshell sandbox create \
 --from "$INSTALL_DIR" \
 --name "$SANDBOX_NAME" \
 --no-tty \
 --forward "$GATEWAY_PORT" \
 -- /app/entrypoint.sh

2. Restart the system
3. The openshell gateway and sandbox is ready but the entrypoint command is not run

Environment

• OS: Ubuntu 19
• Docker: 29.4.1
• Openshell: v0.0.54

Logs

Agent-First Checklist

• I pointed my agent at the repo and had it investigate this issue
• I loaded relevant skills (e.g., debug-openshell-cluster, debug-inference, openshell-cli)
• My agent could not resolve this — the diagnostic above explains why

[TaylorMutch]

📋 triage-agent

Triage Assessment

Classification: duplicate of #848

Summary

The reported behavior is real, but the underlying capability is already tracked by #848. Both issues identify the same gap: the public sandbox specification has no persisted startup command, compute drivers launch the supervisor with sleep infinity, and the trailing command supplied to sandbox create is executed only after the sandbox becomes Ready.

Investigation

Current main still has no command field in the public SandboxSpec; field 10 is reserved. Docker, Podman, and Kubernetes inject OPENSHELL_SANDBOX_COMMAND=sleep infinity, while crates/openshell-cli/src/run.rs executes the trailing command as a post-provisioning exec session. Docker restart reconciliation starts the existing container and therefore cannot replay CLI-only state.

#848 predates this report and proposes the direct cross-driver fix: add a command to SandboxSpec, thread it through the compute-driver contract, and deliver it to the supervisor. An unmerged persist-sandbox-command branch also implemented this design, confirming that restart persistence is part of the same capability rather than a separate defect.

Preserve these acceptance criteria from #1805 on #848: rerun the startup command across host/gateway restarts, cover Docker resume as well as Kubernetes, preserve argv boundaries instead of joining command text, and add restart lifecycle tests. The port-forward restart observation is separate from command persistence and should be tracked independently if it remains reproducible; #874 is related to forward supervision and auto-restart behavior.

Recommendation

Close #1805 as a duplicate of #848 and continue the startup-command design and implementation there. Carry the Docker restart reproduction and acceptance criteria from this report into #848.