OpenClaw merged a P1 Gateway and agent-lifecycle fix this morning that turns agent deletion into a fenced, transactional operation. The change landed in PR #111678, titled "fix(gateway): make agent deletion transactional," and it targets one of the more uncomfortable edge cases in any multi-agent system: what actually survives when an agent is removed.
Before this patch, deleting an agent cleaned up the obvious roster-facing state, but several deeper resources could remain alive. The PR body names cron jobs, open SQLite handles, registry rows, directory ownership registrations, and entries in exec-approvals.json as examples of state that could survive deletion. The riskiest case was ID reuse: a newly created agent with the same identifier could inherit command authority from the old one if the previous exec approval allowlist remained behind.
What Changed
The new implementation makes deletion ordered and recoverable. OpenClaw now records deletion work in a durable journal, drains database leases, removes scheduled work transactionally, and only removes the database registry row after cleanup reaches the right point. The PR also adds path-aware fencing so startup reconciliation cannot bring back roster-absent agents from old startup config.
The important pieces are:
- Cron jobs are removed as part of the deletion transaction.
- Agent database handles and leases are drained before the ID can be safely reused.
- Exec approval entries are removed with base-hash protection.
- Cleanup is idempotent, so interrupted deletions can converge on retry.
- Symlink-safe cleanup rules avoid adopting replacement filesystem objects.
That is not just housekeeping. In OpenClaw, agents may own scheduled jobs, approval scopes, workspace state, and database-backed memory. Deleting one needs to mean that all of its authority is retired too.
Why It Matters
The direct user impact is clearer lifecycle behavior: when an operator deletes an agent, it should not continue running cron jobs, holding stale database ownership, or carrying invisible command approvals. This matters even more for teams and long-lived workspaces where agents are created, retired, and recreated over time.
The security boundary is also cleaner. Approval lists are not just preferences; they decide what command surfaces an agent can use without asking again. Removing stale approval inheritance closes a subtle but meaningful authority leak, especially when an ID is reused for a new purpose.
Proof From The PR
The PR includes a broad focused test suite across agent creation, lifecycle registry, cron service behavior, Gateway mutation methods, exec approvals, and state database schema additions. The author reports 361 focused tests passing, plus typecheck, lint, format, and schema guards on a remote test box.
For operators, this is the kind of reliability fix that is easiest to appreciate after it exists. Agent deletion now behaves less like a best-effort cleanup and more like a state transition with durable recovery rules.