dev-prune

From the README

dev-prune

Gigabytes back. Nothing you can't rebuild.

Reclaim the disk space your idle repositories are sitting on — without ever deleting something a lockfile cannot put back.

Website · Documentation · CLI reference · Safety invariants · Changelog

devp is the same binary under a shorter name  ·  Windows, macOS and Linux  ·  Apache-2.0  ·  by VKrishna04

node_modules, .venv, target and vendor are the largest directories on most developers' machines, and the least valuable: every byte in them is described by a lockfile that is already committed. A project you have not opened since March is holding gigabytes hostage for a build you are not running.

dev-prune finds those directories across every Git repository you register, and deletes them — but only after proving the exact command that puts them back would succeed. It knows thirty-six package managers, not just the obvious four: Composer, Bundler, Mix, CocoaPods and Terraform are as first-class as npm and pip. It is one Rust program, installs its own background schedule, and answers to two names you type — dev-prune and devp — alongside a third, windowless build, devpw, that exists only so the Windows scheduled task runs without flashing up a console.

Deleting is only half of it. The same binary puts everything back (devp restore --last-run), sizes and clears the caches those package managers keep outside your projects (devp caches), reports what Docker is holding (devp caches docker), and shows where the disk actually went, drive by drive (devp status, devp stats). One tool for every dependency directory on the machine, instead of one command per ecosystem and a mental note about which ones are safe.

Important

The rule the whole tool is built around: nothing is deleted unless dev-prune has just verified, read-only, that its lockfile can rebuild it. There is no flag to skip that check. --ignore-idle lifts the idle-day wait and nothing else.

Contents

Install

One-liner

Pick the line for the shell you are actually typing into. Pasting the first one into a Command Prompt is the most common install failure there is — it answers 'sh' is not recognized as an internal or external command, because sh is a Unix shell and Windows does not ship one.

Linux, macOS, or a Unix shell on Windows — Git Bash, MSYS2, Cygwin, WSL:

curl -fsSL https://devprune.vkrishna04.me/install.sh | sh

Windows PowerShell — the blue or black PS> prompt, and Windows Terminal's default:

iwr -useb https://devprune.vkrishna04.me/install.ps1 | iex

Windows Command Prompt — the C:\> prompt, which has no iwr of its own:

powershell -NoProfile -ExecutionPolicy Bypass -Command "iwr -useb https://devprune.vkrishna04.me/install.ps1 | iex"

All three download the prebuilt binary for your platform, verify its published SHA-256, put it on PATH, and run dev-prune setup. Pass --no-auto-setup / -NoAutoSetup to skip that last step.

A binary you download and run by hand asks first instead: the first attended run opens the settings walkthrough before anything is installed, finishing it is the yes, and quitting it means nothing is installed — durably, until you say otherwise with devp setup.

Re-run any of them whenever you like. An install that is already current, complete and on PATH is left exactly as it is and exits 0 without downloading; an older one is updated in place; a newer one is not downgraded. --force / -Force writes it again regardless.

The Command Prompt form installs identically to the PowerShell one, but cmd cannot inherit the PATH the installer sets in its own process, so devp resolves in the next Command Prompt you open rather than the current one. PowerShell does not have that problem.

From a package manager

npm install -g dev-prune@latest    # or: npx dev-prune status
bun add -g dev-prune@latest        # same package, through bun
pnpm add -g dev-prune@latest
yarn global add dev-prune@latest   # Yarn 1.x
uv tool install dev-prune@latest   # or: uvx dev-prune status
pipx install --force dev-prune
pip install --upgrade dev-prune
cargo binstall dev-prune           # fetches the prebuilt release archive
cargo install dev-prune            # builds from source, needs Rust 1.88+

Each command installs the latest version and updates an existing copy — the same line works for both. That is what the @latest, --force and --upgrade spellings are for: the bare forms report "already installed" and change nothing, which looks like an update and isn't. (cargo install rebuilds on its own whenever a newer version exists.)

The npm and PyPI packages contain the binary — there is no download step at install time, so they work under npm ci --ignore-scripts, behind a registry mirror and offline. Everything but cargo install ships a prebuilt executable.

npm delivers it the way esbuild and Biome do: one small dev-prune package that lists seven platform packages as optional dependencies, of which npm installs exactly the one matching your machine. That is why there is no download step to block. Windows works from 1.8.0 onwards — earlier versions installed and then reported no binary to run, so a machine still holding dev-prune@1.7.0 needs npm install -g dev-prune@latest.

bun, pnpm and Yarn install that same package, and dev-prune treats each as a channel of its own rather than as npm: a copy bun add -g put there is upgraded and removed with bun. Running npm against it would install a second copy under npm's prefix and leave bun's, still on PATH, at the old version. devp update --channels prints every channel's upgrade command if you want to see the whole table.

crates.io stores source and nothing else, so cargo install has no binary to fetch and always compiles. cargo binstall is the one that downloads: Cargo.toml tells it where this project's release archives live, so it unpacks the same executable the installers use, with no toolchain involved.

Homebrew and Scoop each have a one-file tap and bucket, which exist so that upgrades keep arriving:

brew tap Life-Experimentalist/tap
brew install dev-prune

scoop bucket add life-experimentalist https://github.com/Life-Experimentalist/scoop-bucket
scoop install dev-prune

Both also install straight from a URL with nothing tapped or added, because the file carries the SHA-256 of the archive it installs — but a formula that belongs to no tap is one brew upgrade will never look at again:

brew install https://raw.githubusercontent.com/Life-Experimentalist/dev-prune/main/packaging/homebrew/dev-prune.rb

scoop install https://raw.githubusercontent.com/Life-Experimentalist/dev-prune/main/packaging/scoop/dev-prune.json

dev-prune is not in WinGet yet — winget install VKrishna04.dev-prune does not resolve. On Windows, use Scoop or the install script instead.

The two Python entry points differ in where they land. pip install follows whichever environment is active, so inside a virtualenv devp lives in that venv's Scripts/bin and disappears with it; pip install --user, pipx and uv tool install are the machine-wide forms. Where each one puts the executables.

Direct download

Seven checksummed archives per release on GitHub Releases — Windows, macOS and Linux on x64 and arm64, plus a 32-bit windows-x86 build for machines with no 64-bit mode. The Linux binaries are statically linked against musl, so one file per architecture runs on every distribution including Alpine.

Manual install and build-from-source: docs/RELEASES_AND_MANUAL_INSTALL.md.

In your editor

There is a companion extension. It validates .devprune.json as you type — every key, every adapter name, every enum, from the schema bundled inside it rather than fetched — and puts the workspace's reclaimable size in the status bar, so you can see what a repository is holding without leaving the window.

code --install-extension VKrishna04.dev-prune

Open VSX is the same extension for the editors that cannot reach Microsoft's marketplace — VSCodium, Cursor, Windsurf, Positron, Kiro. You do not have to pick: devp setup offers to install it once, at a terminal, into whichever of those it finds, each from its own registry.

JetBrains IDEs need no extension at all. The config schema is registered with SchemaStore, so IntelliJ, PyCharm, WebStorm, GoLand, RubyMine and Rider validate .devprune.json out of the box — as do Visual Studio, Neovim and Zed.

And your coding agent gets the same treatment. devp skill --agent <editor> writes the rules file that editor actually reads — .github/copilot-instructions.md, .cursor/rules/, CLAUDE.md, .junie/guidelines.md and the rest — so an agent working in the repository knows what dev-prune will and will not delete before it suggests anything.

Claude Code can go first, before devp exists on the machine at all — this repository is also a Claude Code plugin marketplace:

/plugin marketplace add Life-Experimentalist/dev-prune
/plugin install dev-prune@dev-prune

One skill, no hooks and no MCP server, and it is the same SKILL.md the binary embeds. That is the useful order for an agent: read what dev-prune does and refuses to do, then install it.

Everything about editors, in one place: docs/IDE_INTEGRATION.md.

Let an AI assistant do it

Copy the prompt below and paste it to Claude Code, Cursor, GitHub Copilot, Windsurf, or any terminal-capable agent — it installs, verifies, and registers your projects for you. More detail and per-tool notes.

Install and set up `dev-prune` (binary name `devp`), a lockfile-safe workspace cleaner,
on this machine. Follow these steps exactly and do not improvise beyond them.

1. Detect the OS and run the matching official installer, nothing else:
   - macOS or Linux:
       curl -fsSL https://devprune.vkrishna04.me/install.sh | sh
   - Windows (PowerShell):
       iwr -useb https://devprune.vkrishna04.me/install.ps1 | iex
   - If a Rust toolchain is already present and you cannot reach the network, you may
     instead run:  cargo install dev-prune
   Do NOT download binaries from anywhere other than devprune.vkrishna04.me or the
   project's GitHub releases, and do NOT edit PATH, the registry, or any OS scheduler by
   hand — the installer and `devp setup` do all of that themselves.

2. Open a NEW terminal (so the updated PATH is in effect) and verify:
       devp --version
       devp doctor
   `devp doctor` must exit 0. If it prints warnings, read them out to me; do not try to
   "fix" the scheduler or hooks yourself — they are self-installing.

3. Ask me which project directories to keep clean, then register each one:
       devp init <path>
   If I do not have a list, run `devp init --auto --dry-run`, read me what it found, and
   register it with `devp init --auto` once I say yes. Do not register directories I did
   not name or approve. `devp init` only records a directory; it never deletes anything
   on its own.

4. Show me the result and stop:
       devp status

Notes you should rely on, not work around:
- Installation already registered a background pass (every 2 days) and, on Windows, a
  windowless task that never flashes a console window. You do not need to configure any
  of this.
- Nothing is ever deleted unless a lockfile can rebuild it, the repo has been idle past
  the threshold, and (interactively) I confirm. Run `devp run --dry-run` if I want a
  preview.
- To undo the whole thing later: `devp uninstall`.

Every install channel in detail: docs/DISTRIBUTION.md.

Tip

devp is a real executable, not a shell alias. Installation puts a second binary next to dev-prune, so the short name works in cmd, PowerShell, bash, fish, an IDE terminal and a scheduled task alike — with no profile to re-source, and no chance of an upgrade leaving devp on the old version.

Every place it is published

Nine channels, one project. The middle column is the exact string each registry answers to — names this close together are how a typo becomes somebody else's package, so they are worth copying rather than typing.

WinGet is not in the table because dev-prune is not in winget-pkgs yet, so winget install VKrishna04.dev-prune does not resolve.

Two of those rows are not installs of dev-prune at all. SchemaStore is why JetBrains IDEs, Visual Studio, Neovim and Zed validate .devprune.json with nothing installed — the catalog entry points at a schema this repository hosts. And the editor extension is a separate product with a separate version number, released on its own vscode-v* tags, which is why the release marked latest on GitHub is always the CLI.

Anything calling itself dev-prune from anywhere other than these was not published by its author. devp doctor names the channel the running copy came from, and every release archive carries GitHub build provenance that gh attestation verify checks against this repository — a checksum only proves a file arrived intact, which a substituted pair also does.

60-second tour

devp init ~/Projects        # register every Git repository under a tree
devp init --auto            # …or let it work out where your code lives, and register that
devp status                 # dashboard: what is tracked, what is reclaimable
devp run --dry-run          # what a pass would delete — changes nothing
devp run                    # do it, after confirming
devp restore --last-run     # put back exactly what that pass deleted

A few more worth knowing on day one:

devp stats                  # how much has been reclaimed so far, by repository and by package manager
devp history                # which pass reclaimed it, and what started that pass
devp history --pass 1       # the exact command line, and every directory it took
devp caches                 # every package manager cache, sized. The report deletes nothing
devp caches docker          # what Docker holds, and the prune commands
devp caches clear docker    # run the narrow ones — no volume unless you name it, never on a schedule
devp status --drift         # anything installed that the lockfiles don't record?
devp doctor .               # why is this repository not being pruned?
devp doctor --fix           # repair a broken integration — never a first-time install
devp -V                     # version, OS, architecture, config path, PATH audit

What it looks like

Why it is safe

Seven invariants, enforced in code rather than by convention, none of which has a bypass flag. Full detail and the reasoning behind each in docs/SAFETY_INVARIANTS.md.

Verification is read-only by default: npm ci --dry-run, uv lock --locked, cargo metadata --locked, go mod download. Each resolves the dependency graph against the lockfile on disk and fails when the two disagree, instead of quietly rewriting the lockfile and continuing. The writing form runs in exactly two cases — when no lockfile exists at all, and when you have asked with devp config set allow_manifest_rewrite true — because a pass can be started by the OS scheduler while you are away, and a background process that leaves a dirty working tree is a surprise.

Features

Commands

devp hook, devp daemon and devp icon are shorthands for the config subcommands of the same name, and install / uninstall / on / off work wherever enable / disable do — so devp hook install and devp config hook enable are the same command. A misspelled action is rejected rather than quietly reported as status.

--help is the manual: every command and every config subcommand carries long-form help with worked examples — devp run --help, devp config hook --help, and so on at every level — while -h keeps the short version.

Exit codes are a contract: 0 success, 1 failure, 2 unusable arguments. Full flag list, every setting and the --json schema: docs/CLI_REFERENCE.md.

Supported ecosystems

Adapters detect the project, verify the lockfile, and own the bloat directories:

A required binary that is missing is a reason to skip, never a reason to delete: if npm is not on PATH, the node_modules it owns is left exactly where it is.

The eighteen build-tool adapters ship disabled, because a build tree is regenerated by recompiling, not downloading — it costs more to get back. devp config set enable_cargo true / enable_gradle true / enable_maven true / enable_swift true / enable_dart true / enable_mix_build true / enable_vcpkg true / enable_cmake_build true / enable_dotnet_build true / enable_godot true / enable_unity true / enable_unreal true / enable_defold true / enable_cocos true / enable_zig true / enable_stack true / enable_cabal true / enable_sbt true switches them on, and their candidates wait for build_idle_days (45 by default), applied as the maximum of it and idle_days — the build-tool gate only ever makes pruning later, never earlier.

Any one adapter can be made to wait longer than the rest: devp config set adapter_idle_days cargo=90,npm=30 sets a per-adapter floor, applied as max(idle_days, build_idle_days, adapter_idle_days[name]). devp config wizard edits it beside the adapter checklist, grouped by language, where one heading sets the same window for every adapter under it.

A download cache is a bet that re-downloading costs less than the disk it occupies, and somewhere the bet stops paying. devp config set cache_max_gb default=10 is where you say where: a ceiling in gibibytes — GiB, the unit the report prints — for every manager at once, measured against each manager's whole footprint. default=10,npm=4 gives one of them a figure of its own, and a manager named outright is held to that rather than to both. The first run suggests default=10, and any ceiling you have already set counts as the suggestion taken — devp config recommended never overwrites a number you chose. A manager over its cap is marked in devp caches — setting one deletes nothing — and devp caches clear --over-cap all empties exactly what is marked, when you type it. It is keyed by the names devp caches clear takes (npm, pnpm, uv, pip, cargo, go, nuget, …) rather than by adapter name, because the two lists overlap without either containing the other. Empty by default: no cache is too big until you say what too big is. The wizard sets caps as a third column on the same checklist.

The report answers one more question the disk cannot: who still needs this. Beside each manager it says how many of your registered repositories use it, and what its cache works out to per repository — two repositories sharing a cache carry half of it each, which is worth a look; forty sharing that same cache carry a fortieth each, and that is the cache doing its job. A manager no registered repository uses is the one case where a count is enough to act on: everything in it was downloaded for projects that are not on this disk any more, so devp caches clear --unused all costs no re-download for anything you still have. The count ignores whether an adapter is switched on, because the question is which managers your projects use, not which ones a prune pass would touch, and it is shown only for the managers that are also adapter names — pip, conda, nuget, conan and hex get no number rather than a guess. With nothing registered, nothing is counted and --unused refuses to run.

Bundler and Pipenv claim only the install that lives inside the repository: the vendor/bundle a project gets from bundle config set path vendor/bundle, and the .venv that appears when PIPENV_VENV_IN_PROJECT is set. Both tools default to a shared store under your home directory instead, and dev-prune does not go near those at all: a shared gem home or virtualenv directory is where other projects' dependencies are installed, not a cache, and no single lockfile could prove its contents recoverable. For the same reason Composer leaves vendor/ alone entirely when a vendor/bundle is sitting inside it: no composer install puts those gems back.

Any adapter can be switched off outright with devp config set disabled_adapters <names> — a disabled adapter is not detected, not counted by stats, not probed for by doctor and never pruned, exactly as if that ecosystem were not installed.

Tip

Adding an ecosystem is documented end to end in docs/ADDING_ADAPTERS.md — trait, registration, tests.

Repositories with more than one ecosystem

A repository is not assumed to be one project. dev-prune walks the root and up to scan_depth levels below it — six by default, devp config set scan_depth N to change it, or "scan_depth" in a repository's .devprune.json for just that tree. Every directory a package manager recognises is verified and pruned on its own terms. All three of these work:

monorepo/                          monorepo/                     monorepo/
├── package-lock.json              ├── frontend/                 ├── Cargo.toml
├── uv.lock                        │   └── pnpm-lock.yaml        ├── web/
└── Cargo.toml                     ├── services/api/             │   └── package-lock.json
                                   │   └── uv.lock               └── scripts/
   three managers, one root        └── tools/cli/                    └── requirements.txt
                                       └── Cargo.toml
                                                                  root + nested, mixed
                                    one manager per subtree

Results are reported by repository-relative path, so a monorepo reads unambiguously:

  • MyMonorepo → frontend/node_modules [pnpm]
  • MyMonorepo → services/api/.venv [uv]
  • MyMonorepo → tools/cli/target [cargo]

The walk never descends into node_modules, target, vendor, virtual environments, hidden directories, or nested repositories — a submodule is pruned as itself, never as part of its parent.

When npm, pnpm, yarn and bun all claim the same node_modules, exactly one is chosen, strongest signal first:

1. the packageManager field in package.json,
2. the bookkeeping files inside the installed tree (node_modules/.pnpm, .yarn-state.yml, .package-lock.json) — whoever built what is actually on disk,
3. the most recently written lockfile.

For Python, uv or Poetry takes the environment whenever it recognises the project — between the two, whichever one's lockfile is actually on disk wins — and the requirements.txt adapter handles everything else.

If you write JavaScript

node_modules is usually the largest directory in a JavaScript repository, and every project you have stopped touching still has one. dev-prune proves the lockfile can put it back before deleting it (npm ci --dry-run, pnpm install --frozen-lockfile --lockfile-only and the rest, all read-only), and only once the repository has been idle for idle_days:

devp run --dry-run      # which node_modules would go, and how much each frees
devp run -y             # delete them
devp restore .          # back in this project: npm ci, pnpm install, yarn or bun

devp restore --last-run reinstalls everything the last pass deleted, across every repository it touched. A node_modules holding a package installed with npm install --no-save is refused rather than pruned, because the lockfile cannot bring it back; devp status --drift lists those ahead of time with the npm install <pkg> that records them. Build output such as dist/ or .next is never touched.

If you write Python

A .venv holds its own copy of every package the project installed, and a few old projects with machine-learning dependencies can hold several gigabytes each. dev-prune verifies each environment against the tool that built it (uv, Poetry, PDM, Pipenv, pixi, or a plain venv beside a requirements.txt) and refuses one holding a package that was pip installed by hand and never recorded; devp status --drift names those and the uv add or pip freeze > requirements.txt that fixes it.

devp restore . rebuilds the environment with the same tool (uv sync, poetry install, pdm install, and so on). devp restore --last-run rebuilds each one on the Python version it was first built with, read from its pyvenv.cfg, because a 3.12 environment rebuilt on 3.14 can resolve different wheels. If that version is no longer installed, it asks once and prints the uv python install line that fixes it.

__pycache__, .pytest_cache, .mypy_cache and .ruff_cache go too. They refill on the next import or test run, so there is nothing to restore.

Configuration

Global settings live in %APPDATA%\dev-prune (Windows), ~/Library/Application Support/dev-prune (macOS) and $XDG_CONFIG_HOME/dev-prune (Linux). devp config wizard opens all of them in a full-screen configurator, and runs itself once on a first install — so the defaults are something you agreed to rather than inherited — and again after an upgrade adds a setting you have never been shown.

If you already know what you want, devp config recommended is the one-command version: it turns on the eighteen adapters and build trees that are off by default because they are not universally wanted, and leaves allow_manifest_rewrite — the one recommendation that edits files Git tracks — named, explained and off unless you add --with-cautious. devp config show lists whatever you have not taken yet.

Forty-one settings, in the seven groups the configurator asks them in — the order the decisions actually arrive in. Every key, with its full description and range, is in the CLI reference.

The language this is all in — what dev-prune prints its own headings in.

What gets pruned — the size and age of what a pass considers at all.

Before anything is deleted — what stands between a candidate and a deletion.

Build trees — off by default, because everything here comes back by recompiling rather than downloading. That is the whole reason each one is a switch.

Shared download caches — one key, because the cap only ever marks.

Running without being asked — what dev-prune may install here, and how often it may act on its own.

Keeping dev-prune current — whether this copy looks for a newer one, and may install it.

Per-repository settings

Three of them — idle_days (as override_idle_days), min_size_mb and scan_depth — also take a per-repository form, where they win for that tree only. The rest are deliberately global: a repository you have never read should not be able to grant itself permission to have its manifests rewritten during an unattended pass.

A repository can hold two config files, and the difference is who they are for.

Where both exist, every key the project file names wins, and the personal file answers everything it does not. That is the inverse of the usual "local overrides global", and deliberately: a colleague's stale local answer should not quietly overrule what the project decided, while a personal override still works on every setting the team left open. "Names a key" means the key is literally in the file — a project file that never mentions ignore does not un-ignore your repository, which is why it is created holding nothing but its $schema line.

Nothing dev-prune writes on its own touches the shared file. devp link, devp doctor --fix, devp config project . --update and [i] in the dashboard all write .devprune.json, so no routine action of yours turns into a change on a branch your colleagues share; --team is the only way to write the other file, and you have to type it. Run devp config project . in a repository that has both and it prints which file each effective value came from.

Directories only the project knows about

Every adapter earns its right to delete the same way: it finds a lockfile, verifies the lockfile can rebuild what is about to go, and only then deletes. Some trees have no lockfile and are still rebuildable — a generated fixture set, a vendored toolchain, a cache with a make target behind it. A repository can name those itself, in either config file:

{
  "prunable": {
    "directories": [
      {
        "path": "tools/vendor",
        "rebuild": "make vendor",
        "why": "regenerated from tools/manifest.toml"
      }
    ]
  }
}

rebuild is required, and required is the point: an optional one would make "delete this, I have no idea how to get it back" the easiest thing to write in a file that gets committed and cloned. If a directory genuinely needs nothing to bring it back, say so — "rebuild": "echo not needed" is a legal answer and works on every platform. dev-prune shows the command; it never runs it.

Declared directories go through the ordinary pass under the adapter name declared, so they are listed by devp status, obey --dry-run, --min-size and --only, and are deleted by the scheduled run alongside everything else.

A declaration is a claim, not an instruction. project.devprune.json is committed, so a repository you cloned can declare whatever it likes, and devp run may be running from a scheduler with nobody watching. Before deleting one, dev-prune requires that:

• the path is relative, has no .., and is neither .git nor the repository root;
• it resolves to somewhere inside the repository, even through a symlinked parent;
• Git is tracking nothing inside it — a lockfile cannot rebuild a file that is in the repository itself;
• the first word of rebuild is a program this machine actually has;
• and the target that program was given is one it could actually find, wherever a manifest already in the tree can answer for it — an npm, pnpm or yarn script in package.json (honouring --prefix), a make target, a uv run entry point in [project.scripts], a cargo subcommand. npm run build against a package.json with no build script is refused, because installing node proves nothing about whether that command would put the directory back.

Every one of those is a read of a file. The rebuild command is printed, never run — not even a dry run of it. A command shape no manifest can resolve, such as a shell pipeline or a target held in a variable, is allowed through on the checks above rather than guessed at: a false refusal blocks a prune that was safe.

A claim that fails any of those is printed with the reason, and nothing is deleted.

This section is the one part of either file that does not follow the precedence above: the two lists add up. A list is not a decision, so a team declaration never discards one you wrote yourself, and naming the same path in both leaves one directory, rebuilt by the committed command.

And because the committed file is the whole team's, one declaration can be right for everybody but you — the directory the project regenerates is the one your copy happens to be holding something in. prunable.exclude is how you say so without editing a file your colleagues share:

{ "prunable": { "exclude": ["tools/vendor"] } }

Spelled the way a path is, so tools/vendor, tools/vendor/, ./tools/vendor and tools\vendor are one path; an exclusion that missed on a trailing slash would delete the exact directory it was written to keep. It is honoured from whichever file names it, because a veto only ever deletes less, and the entry it names leaves the pass entirely — not deleted, and not reported as a refusal on every run either. Naming the same path in both lists of one file is a typo rather than a decision, since the exclusion wins and the declaration then never runs; devp doctor points that out. Delete the exclusion and the declaration is back in force.

An out-of-range value is rejected with the range in the message rather than silently clamped. scan_depth included: config set accepts 1–32 and refuses anything else outright — the clamp to that range survives only as the backstop for a hand-edited config file.

Background automation

Installation registers an OS-native scheduler — Windows Task Scheduler, a macOS LaunchAgent, or a systemd user timer — that runs a pass every check_interval_days, plus non-blocking post-commit, post-checkout and post-merge Git hooks that register new repositories as you visit them. Both are reinstated after an upgrade if anything went missing.

None of it arrives unasked. A machine that has never agreed opens the settings walkthrough on its first attended run, before anything is installed: finishing the walkthrough is the yes, quitting it is a durable no, and devp setup changes the answer whenever you like.

devp setup --status              # what is installed, what is not, and why
devp config set auto_setup false # stop the unattended pass entirely
devp uninstall                   # remove the scheduler, hooks and the devp link

Git allows exactly one global core.hooksPath, so a tool holding it shuts every other one out machine-wide. devp hook install --chain takes the slot and forwards each hook on to the tool it displaced — husky, pre-commit and lefthook keep firing, in order, with their own exit codes. It is opt-in, because rewiring another tool's Git configuration unasked is not something an install should do.

Full decision flow: docs/BACKGROUND_AUTOMATION.md.

How it compares

Longer analysis: docs/MARKET_ANALYSIS.md.

Architecture

• Registry — Serde-backed, written atomically, holding registered paths and settings.
• Engine — coordinates activity discovery, verification and space calculation.
• FastIgnore — presence check for ignore.devprune.json; no read, no parse.
• GitScanner — git log timestamps plus source-file mtime.
• PreCheck — confirms the package manager binaries a pass will actually need.
• Adapters — one per ecosystem, each owning detection, verification and restore.
• LockfileCheck — the gate; failure aborts the deletion and prints the exact fix command.
• Daemon / GitHooks — the unattended pass, and registration as you work.

Deeper: docs/ARCHITECTURE.md · HLD · LLD.

Documentation

License & privacy

Copyright 2026 VKrishna04. Licensed under the Apache License, Version 2.0 — see LICENSE.md. Every source file carries an SPDX identifier, so automated licence scanners see the same answer the file header does.

Important

No analytics, no diagnostics, no usage data — none collected, none sent. Your workspace structure, directory paths and repository names never leave the machine.

On its own, dev-prune makes one network request: an unauthenticated GET to GitHub's public releases endpoint, to tell you when a newer version exists. It has no body, carries no identifier, and runs at most once a week. Turn it off with devp config set update_check false. Because auto_update is on by default, a newer release that check finds is downloaded and verified at the end of a prune pass; devp config set auto_update false leaves that to you. Full detail in docs/PRIVACY.md.