OpenClaw’s Docker Agent-Delete Bug Is Really About Reversible Destruction Semantics

Deletion semantics are boring until an agent disappears from config but its workspace, sessions, and state are still sitting on disk. OpenClaw issue #84121 reports exactly that Docker-shaped failure: deleting an agent can remove it from openclaw.json while leaving physical directories behind under .openclaw, including workspace/, agents/, and sessions/. Maintainers closed the issue as duplicate/superseded by #83459, but the design problem is worth covering. Agent deletion is data-lifecycle governance, not cleanup trivia.

The report points to two paths. The CLI path calls a trash binary that is missing from the official Docker image. The Gateway path uses the JavaScript movePathToTrash helper from @openclaw/fs-safe, which may be weaker across bind mounts or filesystem boundaries than a system trash implementation. The suggested fix is sensible but policy-laden: add trash-cli to the official Docker image and use a shared best-effort trash flow — system trash first, JavaScript fallback second, optional rename/move or hard-delete only if explicitly chosen for forced deletion.

“Deleted” has to mean more than config removed

The reported environment is Docker with /root/.openclaw bind-mounted. That matters because a bind-mounted state directory is not disposable container scratch space. It is operator-owned durable state exposed through the container. When deletion updates config but leaves directories behind, the system creates a bad in-between state: the agent is no longer active, but its physical artifacts remain. That can mean stale disk usage, confusing audits, accidental resurrection paths, leftover session data, and mismatched operator expectations.

The opposite failure is also bad. If a trash operation fails and the platform silently falls back to rm -rf, it violates a different contract: reversible destruction. OpenClaw’s maintainer caution is correct here. Any hard-delete fallback needs an explicit maintainer decision because current behavior and documentation promise Trash rather than irreversible deletion. That is not being precious. Personal and work agents can accumulate session history, local files, memory, credentials references, and channel state. Destroying that data without a clear user choice is worse than leaving a cleanup task behind.

Docker complicates the user model. On a desktop, “move to Trash” implies OS-level behavior the user understands. Inside a container, that behavior depends on whether trash-cli exists, what UID owns the mount, how the mount handles trash directories, whether cross-filesystem moves work, and what fallback behavior the runtime implements. A JavaScript helper can be perfectly reasonable for ordinary paths and still fail to match operator expectations across bind mounts. The runtime has to surface that nuance instead of pretending deletion is one syscall.

Reversible, consistent, observable

The maintainer response usefully narrowed the thread: consolidate under #83459, acknowledge that the Docker CLI failure has source-backed support — official image lacks trash-cli, CLI only calls trash — and require concrete logs or repro before expanding the separate Gateway bind-mount claim. That is good governance. A duplicate issue should not silently widen scope into hard deletion or unproven Gateway behavior.

The architectural answer should have three properties. First, deletion should be reversible by default. Trash before destroy. If hard delete is needed, make it a named, explicit operation with different affordances and warnings. Second, deletion should be consistent across CLI and Gateway. Operators should not get different lifecycle outcomes depending on whether they clicked in a UI or ran a command. Third, deletion should be observable. The result should say what happened: config removed, workspace trashed, sessions trashed, agent directory trashed, failures listed, and no hard-delete attempted.

That last point is critical. “Agent deleted” is not enough. A platform should report the lifecycle of each relevant path. If the workspace moved to trash, where did it go? If sessions could not be moved because a bind mount rejected the operation, say so. If the config was updated but physical cleanup failed, the operation should return a partial-success state. Users can handle partial success. They cannot handle a green check that hides stale state.

For practitioners running OpenClaw in Docker, the immediate checklist is practical. Before deleting agents, understand where .openclaw is mounted. After deletion, inspect the mounted state directory and confirm whether data actually moved to trash. For production-ish or personal long-running agents, treat deletion as a two-phase lifecycle action: remove from active config, then verify state cleanup or archival. If you need irreversible deletion for compliance or disk-pressure reasons, do it deliberately and document the evidence.

This belongs under agent runtime governance because governance does not stop at tool permissions. It includes identity lifecycle: create, isolate, run, audit, archive, disable, delete. The industry is excited about autonomous actions, but the operating-system-shaped parts are where trust is built. An agent platform that cannot explain what happened to an agent’s data after deletion is not ready to be treated as infrastructure.

The important bug is not merely “Docker forgot trash-cli.” It is that agent platforms need deletion semantics that are reversible, consistent, and observable. Anything less leaves operators choosing between ghosts on disk and irreversible surprises. Neither is LGTM.

Sources: GitHub issue #84121, issue #83459, OpenClaw v2026.5.19-beta.1, PR #84128