openclaw agents delete recursively removes the workspace directory, including shared/template state

Version affected: OpenClaw 2026.4.14 (323493f) on macOS Severity: data-loss (silent, unbounded blast radius when workspaces are shared across agents)

Summary

openclaw agents delete <id> --force removes the entire workspace directory referenced by the agent — not only the agent-specific state under ~/.openclaw/agents/<id>/. When a workspace is shared across multiple agents (common pattern for canary/test agents reusing a template workspace path, or when two agents intentionally share identity), deleting one agent silently destroys the shared workspace contents that belong to the others.

Reproduction

# Setup: add agent-A, which creates ~/.openclaw/workspace-shared/ with template files
openclaw agents add --workspace ~/.openclaw/workspace-shared \
  --non-interactive --json agent-A

# Add a second agent that reuses the same workspace
openclaw agents add --workspace ~/.openclaw/workspace-shared \
  --non-interactive --json agent-B

# Delete ONE of them
openclaw agents delete agent-A --force --json

# Observe: ~/.openclaw/workspace-shared/ is GONE
ls ~/.openclaw/workspace-shared
# → No such file or directory

agent-B is left in the registry pointing at a workspace path that no longer exists on disk. Any files that were in the workspace (AGENTS.md, SOUL.md, custom skills, memory, DREAMS.md, etc.) are gone.

Expected behavior

delete should only prune state that is unambiguously owned by this agent id:

1. Remove the entry from ~/.openclaw/openclaw.json agents.list[*] where id == <id>.
2. Remove routing bindings referring to this agent.
3. Remove ~/.openclaw/agents/<id>/ recursively (that dir IS agent-specific).
4. Remove the workspace dir only if no other agent in the registry references that same workspace path. Otherwise, leave the workspace untouched (and note in --json output: "workspaceRetained": true, "workspaceSharedWith": ["agent-B"]).

Alternatively, add an explicit opt-in flag --prune-workspace that defaults to false. This makes the destructive behavior an explicit choice rather than a silent default.

Why this matters

This bit us today in two places:

1. Our canary-deployment testing pattern used --agent-id-override canary-<ts> but left workspace as the spec's default path. Teardown nuked the shared template.
2. A Wave4u E2E test on 2026-04-23 accidentally wiped ~/.openclaw/workspace-hello-world/ which was the reference template for a production agent deploy. Files were recovered only because the outer ~/.openclaw git repo had the workspace under allowlist tracking and we could git checkout -- workspace-hello-world/. On a non-git workspace or with unstaged local edits, the data would have been unrecoverable.

Workaround we deployed

Added --workspace-override flag to our own provision_agent.py so canary runs can pass --workspace-override /tmp/canary-ws-<ts> and isolate the blast radius. This protects us but doesn't protect anyone else using openclaw agents delete the naive way.

Discovered

2026-04-23 by Wave4u during independent verification of agent-deployer. Full post-mortem in today's conversation thread; workaround commit dda96db in ~/.openclaw.