fix(governance): rm -rf inside the agent's own workdir not destructive (v0.264.3)

[vikasprogrammer]

What & why

Follow-up from monitoring the fleet after the enricher fixes. A residual false positive surfaced: an agent cleaning up a dir inside its own home, by absolute path was still hard-denied:

rm -rf /home/ubuntu/tools/agent-os/data/agents/engineer/work/client-app/au-registration-support
# "clean up my broken/pruned worktree dir"

The v0.260 path-safety only whitelisted /tmp + relative paths, not the agent's own workdir subtree — so a legitimate self-cleanup via absolute path read as destructive.

Fix

isSafeDeletePath now treats a strict subpath of the agent's workdir as safe (same principle as the outsideWorkdir fact for file writes — an agent operating inside its own folder is doing its own work). Threaded the existing workdir param through rmTargetsAllSafe.

Still denied (verified): the workdir ROOT itself (wiping the whole agent home), a sibling agent's home, a .. escape out of the workdir, /etc, and any unrelated absolute/system path.

Verification

• npm run build ✓ · npm run test:governance → 102/102 ✓ (4 new golden cases)
• 9/9 against the exact fleet command + safety cases.

Monitoring context

This came out of a post-deploy fleet scan: 0 denials since the fixes went live (instapods 0/24h, instawp 40 decisions/0 deny since restart, expresstech 1/0); the pre-fix denials in-window were all known-and-fixed families. This absolute-workdir rm was the one genuinely-new FP form. One softer residual remains (a ssh 'bash -s' <<EOF heredoc whose script text mentions "suspend" trips userSuspend@approve) — left as a known limit since interpreter heredocs must be scanned for safety.

🤖 Generated with Claude Code

https://claude.ai/code/session_019zMSbnPEbqSVPGLasTKENp