OpenClaw merged a high-priority Gateway compatibility repair this morning in PR #145426, a fix for multi-agent installations where one secondary agent's copied SQLite database could block the entire Gateway from admitting otherwise healthy agents.
The problem was sharp because it turned a localized state conflict into an outage-shaped failure. If one secondary agent had a divergent copy of another agent's database, OpenClaw could refuse startup paths broadly enough that healthy agents could not serve requests and Doctor could not finish the independent repair work.
The merged patch changes that posture. OpenClaw now records typed ownership refusals per configured database file at startup, then routes status, session listing, chat metadata preparation, recovery, Doctor, and scheduled work through that admission decision. Default/system-agent and shared-state failures still remain fatal, but a secondary agent with a conflicting database is isolated instead of poisoning the full Gateway.
What Changes For Operators
The biggest operational change is availability. A multi-agent Gateway can keep serving unaffected agents while reporting the broken one clearly.
The PR says divergent files are preserved, and Doctor now uses existing inspection and quarantine guidance for the recovery owner. That is the right default: preserve the evidence, keep healthy work moving, and make the repair path explicit.
For an operator, the new behavior should look like this:
- Healthy agents remain available.
- Requests to the affected agent return the recorded refusal reason.
- Agent lists, status output, Doctor, and automation previews identify the issue.
- After file repair, the next startup recomputes admission and can admit the agent again.
That last point matters because this is not a hidden durable override. The PR does not add a clearance record, protocol bump, schema migration, or config escape hatch. It recomputes from the actual database files after the operator fixes the underlying conflict.
Why This Was P0
This repair is labeled P0 and merge-risk: compatibility, which fits the blast radius. Multi-agent OpenClaw setups are exactly where users expect isolation: one agent's damaged or copied store should not prevent unrelated agents from answering, scheduling, or showing status.
The PR also follows an earlier duplicate-only recovery path in #144714. This morning's patch broadens the protection from duplicate ownership into divergent database-copy handling, while still keeping the system-agent and shared-state boundaries strict.
The Practical Takeaway
If you run OpenClaw with several agents, this is one of those fixes that may never show up as a flashy UI change but will matter during a bad upgrade or manual file recovery. The Gateway is becoming more granular about what is broken, which means less downtime when only one agent's store needs attention.
Watch for this in the next OpenClaw release notes if your deployment has multiple configured agents, especially if you have ever copied agent directories, restored partial backups, or repaired state files by hand.