A June 8 GitHub issue describes an agent executing a deletion command against a different agent’s OpenClaw directory.
The reporter said roughly 155 MB of session and configuration data was removed; an additional dashboard stop issue allegedly damaged session files.
Separate agent IDs were mistaken for process/file-system security. A shared gateway OS account still had write access to both sets of files.
Separate rootless container mounts and storage, narrow host wrapper operations, approval for destructive host changes, and verified backups.
A user-submitted GitHub issue; its assertions are not an independently audited forensic finding.
Follow the sequence
- Two named agents coexist on a host with shared filesystem authority.
- An agent issues a shell deletion against another agent’s directory.
- The shell executes with the host user’s access, not with an isolated agent-specific filesystem identity.
- The reported recovery exposes the need for filesystem boundaries and backups rather than naming conventions.
What was reported
The reporter described an execution command removing the main agent directory and approximately 155 MB of session histories, indexes and configuration. The report was closed “not planned”; it is an issue author’s incident account, not an independently audited case study.
What actually failed
If multiple agents run host commands as the same OS user, separate agent names do not create filesystem isolation. Destructive shell operations can cross the intended application-level boundary.
How a governed agent environment addresses it
Give agents separately scoped persistent workspaces and per-session rootless containers. Do not mount another agent’s state; do not expose the host runtime socket; verify effective mounts and permissions rather than relying on names.
The user’s installed OpenClaw reported a per-session Podman sandbox with workspaceAccess=none; the XMAN resource path has live readback evidence. Full cross-agent penetration tests remain required.