OpenClaw has merged a P1 fix for SSH sandbox secret ownership. PR #110081, fix: keep broken SSH sandbox refs agent-scoped, landed at 22:56 UTC on July 17.
The short version: one broken SSH sandbox secret should no longer take down Gateway startup or interfere with unrelated agents. That is a security and availability boundary worth watching for anyone running multiple agents with different remote sandbox identities.
The Failure Mode
The PR describes a case where users with one broken SSH sandbox SecretRef could lose Gateway startup or unrelated agent sandboxing. Worse, an unresolved direct SSH identity could fall through to ambient filesystem or agent configuration.
That is exactly the kind of edge case agent operators do not want. A failed remote sandbox should be noisy and contained. It should not silently borrow another identity, and it should not make healthy agents unavailable because one agent's SSH reference is broken.
What Changed
OpenClaw now assigns exact normalized agent owners during sandbox secret collection. It duplicates inherited defaults only for relevant agents and ignores unrelated per-agent overrides in shared scope.
The sandbox resolution and SSH manager paths also validate two things before filesystem or network access:
- the effective agent owner;
- the selected raw SSH references.
If a secret is unavailable, OpenClaw returns the existing typed unavailable error for that agent only. Healthy agents can continue to start and use their own sandboxes.
The PR also keeps SSH lifecycle credentials materialized while SSH remains configured. That detail matters for operations: disabling an agent or sandbox should not strand inspection or removal of an existing remote runtime.
Why It Matters
Multi-agent systems need boring ownership rules. Secrets, sandboxes, and remote runtimes are high-risk surfaces because they often determine which machine an agent can touch and under which identity.
PR #110081 narrows the blast radius of a broken SSH sandbox configuration. A bad secret becomes an agent-local problem, not a Gateway-wide startup failure and not a chance to fall back into another identity.
The PR does not add a new config, environment variable, UI, protocol, or capability surface. That is a useful sign for a hardening change: the fix sits in ownership and validation paths instead of asking users to configure around the bug.
Evidence
The PR reports 48 focused tests passing across runtime secrets, sandbox secret ownership, SSH backend behavior, and Gateway startup secret-owner isolation.
It also reports a hosted changed gate across the affected sandbox, secrets, and Gateway files, plus a fresh autoreview with no accepted actionable findings after the lifecycle repair.
Operator Takeaway
If you run OpenClaw with several agents and SSH-backed sandboxes, this is a meaningful reliability fix. One agent with a broken SSH secret should now stay cold while the rest of the system remains available.
More importantly, direct SSH secret resolution should fail closed instead of drifting into ambient identity. That is the right default for agent infrastructure, where accidental authority is often more dangerous than an explicit startup error.