dev-prune

Giving an AI agent a safe way to free disk space

An agent that runs rm -rf has no dry run, no proof and no undo. What to demand of any cleanup an agent performs, and how to teach yours the safer path.

Updated 2026-09-20

Coding agents notice full disks. They see the failing write, they know node_modules is rebuildable, and the shortest path from problem to fix is rm -rf. Sometimes that is fine. The times it is not fine are the times a lockfile no longer resolved, or the directory held something edited in place, or the command was docker system prune --volumes and the thing reclaimed was a database. An agent deleting by hand has no dry run, no proof the thing comes back, and no record to undo from.

What to demand of any deletion an agent performs

The bar is the same whether the agent is a person or a model, but a model needs it written down:

  • A dry run first. The plan is shown before anything is deleted, and the real run does exactly what the plan said.
  • Proof of recoverability. Not "this is usually rebuildable" but a check, run now, that this particular directory rebuilds from what sits beside it.
  • A record and an undo. Every deletion is written down, and one command puts it back.
  • Refusals that cannot be scripted around. The dangerous paths refuse piped input and auto-confirm flags, so the agent can prepare the command but only a person can run it.

dev-prune is those four bullets as a binary. devp run --dry-run is the plan; lockfile verification runs before every deletion and has no bypass flag; devp history records each pass and what started it; devp restore --last-run reinstalls exactly what the last pass removed. The one path that can touch a container volume takes each deletion as a typed pick and refuses --yes, --json and piped stdin, so an agent can run the --dry-run form and hand the final command to you, and nothing more.

Teaching the agent it exists

An agent uses the safer path only if it knows the path is there. devp skill handles that: on its own it reports which coding tools this machine or repository shows traces of (pure existence checks, nothing executed), and with --agent or --detected it writes a rules file into the current repository in the place each editor's agent actually reads: .cursor/rules/ for Cursor, .windsurf/rules/ for Windsurf, a marked block in AGENTS.md for the tools that read the shared convention, and a dozen others.

devp skill                    # what is detected, and what is current or missing
          devp skill --agent cursor     # rules for one editor
          devp skill --detected         # rules for every detected editor at once

The rules are inert text, safe to commit, and they say the things above in the agent's terms: never rm -rf a bloat directory by hand, restore through devp restore rather than reinstalling manually, never touch a volume, never empty the Maven local repository uninvited. Claude Code is the one tool not written per repository, because its skill installs globally and every project gets it.

When rules are not enough

Rules are advisory: a long session can bury them. Harnesses with command hooks can turn the two rules that matter most into a real confirmation prompt, so a volume deletion the agent composes stops and asks you first. A copy-paste hook for Claude Code, with the matching patterns and the reasoning, lives in the IDE integration guide.

Common questions

How do I stop my AI agent deleting node_modules by hand?

Give it a better path and write the rule where it reads. devp skill --detected writes a rules file for every coding tool your repository or machine shows traces of, and the rules say to prune through devp run (which verifies the lockfile first and records the deletion) and to put things back with devp restore. For a harness with command hooks, the IDE integration guide has a hook that turns the dangerous commands into a confirmation prompt.

What if the agent already deleted a dependencies directory?

If dev-prune deleted it, devp restore reinstalls it, and devp history shows which pass took it and what started that pass. If the agent ran rm -rf itself, there is no record to restore from: reinstall from the lockfile with your package manager, and check the lockfile still resolves before trusting the result.

Can an AI agent delete Docker volumes through dev-prune?

No. The only command that touches volumes lists them by name and takes each deletion as a typed pick at an interactive terminal; it refuses --yes, --json and piped stdin, which are the three ways an agent answers prompts. The agent can run the --dry-run form, which lists the unused volumes and prints the command for a person to run, and that is the intended division of labour.

Keep reading