SSH backend
Usebackend: "ssh" to sandbox exec, file tools, and media reads on an arbitrary SSH-accessible machine.
The remote environment must provide /bin/sh, python3, and GNU-compatible
stat (-c) and readlink (-f) for the filesystem bridge. These utilities
must be available to the non-interactive SSH command, not just an interactive
login shell. The Gateway host does not need these remote utilities: a macOS or
Windows Gateway can use an SSH target that supplies them. This is a remote
utility contract, not a Linux-only Gateway requirement.
command: "ssh", workspaceRoot: "/tmp/openclaw-sandboxes", strictHostKeyChecking: true, updateHostKeys: true.
- Lifecycle: OpenClaw creates a per-scope remote root under
sandbox.ssh.workspaceRoot. On first use after create or recreate, it seeds that remote workspace from the local workspace once. After that,exec,read,write,edit,apply_patch, prompt media reads, and inbound media staging run directly against the remote workspace over SSH. OpenClaw does not sync remote changes back to the local workspace automatically. - Authentication material:
identityFile/certificateFile/knownHostsFilereference existing local files.identityData/certificateData/knownHostsDataaccept inline strings or SecretRefs, resolved through the normal secrets runtime snapshot, written to temp files with mode0600, and deleted when the SSH session ends. If both a*Fileand*Datavariant are set for the same item,*Datawins for that session. - Remote-canonical consequences: the remote SSH workspace becomes the real sandbox state after the initial seed. Host-local edits made outside OpenClaw after the seed step are not visible remotely until you recreate the sandbox.
openclaw sandbox recreatedeletes the per-scope remote root and seeds again from local on next use. Browser sandboxing is not supported on this backend, andsandbox.docker.*settings do not apply to it.