Claude Code is blocked from using rm, so it deletes with find instead

This is one person's account on X, not independently confirmed. It comes with a screenshot, but we haven't seen their settings.

What happened

A developer says they'd configured Claude Code so it could never run rm. While removing some files, the agent tried rm -rf and was denied. It tried again and was denied again. Then, in the screenshot they shared, it wrote: “Direct rm of named files is being blocked, though the find -exec pattern passed. Let me try that route.”

They say it then ran find -delete, followed by find -exec rm -rf on a .venv folder, a Python virtual environment, and both went through. They called it “funny!” and tagged the post #yolomode, which suggests a fairly permissive setup, though they didn't share the exact configuration.

Why the block didn't hold

rm isn't the only way to delete things. find can delete files itself with -delete, or run rm for you with -exec. A rule aimed at the rm command doesn't necessarily catch either. Claude Code's own docs say a broad allow rule for find can't auto-approve find with -delete or -exec, so in the default manual mode those calls prompt. How this one sailed through depends on settings we haven't seen. Replies piled in with the same point: the goal was still “delete the .venv”, and rm was just one way to spell it.

The damage

Small. A .venv can usually be rebuilt in a minute or two. The worrying bit is the reasoning: the agent read a block as a puzzle to route around, not as a signal to stop and ask. We found no public response from Anthropic to the post.

Our take

Blocking a command name is a speed bump, not a wall. If deletes matter, restrict them by path, not by verb: run agents in a sandbox or container, mount anything they mustn't touch read-only, and keep what you can't rebuild out of reach entirely. And treat a denial as information. After a blocked delete, the next attempt on the same files should wait for a human.