v1.17.0

Added

• devp caches clear docker (also podman, nerdctl, finch and Apple's
  container) runs the container prune commands the report has been printing since
  1.13.0, instead of asking you to go and type one in another window. Build cache, unused
  images, stopped containers — printed first, after a prompt, and counted on its own line
  in devp stats, so the 20 GiB you reclaimed on dev-prune's advice is space dev-prune
  can actually account for. --dry-run shows the commands and the estimate and touches
  nothing.

  It will not touch a volume, and there is no flag that makes it. No argument anywhere
  in its table contains the word, and a unit test fails the build if one appears. An image
  can be pulled again and a build cache rebuilt; what is inside a named volume is the only
  copy. docker volume prune stays a command it prints and you type — and the estimate
  has the engine's unused-volume figure taken out of it and named separately, rather than
  promising back space these commands cannot give.

  Nothing on a schedule reaches any of this: no daemon, no Git hook, no devp run, and
  not devp caches clear all either. Naming the engine is the consent.
  Reference

• How a repository gets registered
  is every way a repository can land on a machine, and which of the three mechanisms
  catches it. A repository you unzipped, copied from another machine, restored from a
  backup or received over Dropbox never runs git, so no hook can ever fire for it —
  discovery is what covers those, and the table says so instead of leaving you to work it
  out. It also names the one case that still needs a hand, and what is skipped on purpose.

• devp history answers the question devp stats raises. That report says ten passes
  freed 27.66 GiB; this one says pass #2 ran at 09:14 as devp run --daemon, took
  4.02 GiB out of two repositories, and names all three directories it deleted. Bare, it
  is one line per pass. devp history --pass 1 opens one in full: the exact command line,
  the version that ran it, and every directory removed with its package manager and size,
  grouped by repository.

  It records what started each pass, which nothing did before — manual if you typed
  devp run, scheduled if it was the background pass, dashboard if it was the [p]
  key in devp status. There are three ways to start a prune and those are all three, so
  "was that me or the daemon?" now has an answer rather than an inference.

  Long output has three exits rather than a truncation: detail is per-pass and opt-in, the
  directory list is capped at 200 entries only when it is going to a terminal (redirect
  or pipe it and nothing is elided), and devp history --export writes the whole document
  to your documents folder — or to exactly the path you name.

  Passes from before this release still appear, marked (totals only): their four numbers
  were always in the registry, and a history that started empty next to a devp stats
  reading "10 prune passes" would look like a bug rather than a gap. devp history --json
  carries detail: false on those, so a script can tell "deleted nothing" from "nobody
  wrote it down".
  Reference

• devp caches now finds the stores that were quietly the largest things on the disk.
  Playwright and Puppeteer keep a whole browser build per version, Cypress an unpacked
  Electron application per version, and none of them ever removes the old one when the
  dependency moves — on the machine this was written on that was 2.9 GiB nothing had ever
  reported. The HuggingFace hub cache, the Electron download cache and electron-builder's
  own store are in the report for the same reason. Each gets the row every other cache
  gets: a size, the path, devp caches clear <name>, and the command that clears it.

  huggingface carries a warning the others do not, because it is the one row where
  "re-download it" is not a promise. A gated or now-private repository will not hand the
  weights back to the token that fetched them last month, a checkpoint from a deleted
  revision is gone, and the re-download is tens of gigabytes rather than tens of
  megabytes. It is cleared like anything else when you type it — with the path printed
  first, so you can look inside before you do.
  Reference

• Six adapters that pruned projects with nothing to show for it now have a cache row.
  devp run has always cleaned a Bundler, pub, SwiftPM, Terraform, Poetry or PDM project;
  devp caches could not see the machine-wide store those projects were reinstalling
  from, so the report answered "where did my disk go" with a gap exactly where the answer
  was. Each is asked where its cache is rather than assumed — gem env gemdir,
  poetry config cache-dir, pdm config cache_dir — and each row names the one
  subdirectory that is genuinely a download cache. That last part is the whole care taken
  here: dart pub cache clean would also delete your globally activated executables and
  your git/ checkouts, and Poetry's cache directory holds virtualenvs/ beside
  artifacts/. dev-prune clears the archives and nothing else.
  Reference

• A Deno adapter, the twenty-fourth. It detects on deno.lock and takes the
  node_modules a Deno project with npm dependencies materialises, sized the way bun's is
  because Deno hardlinks it out of DENO_DIR too. deno install puts it back, and
  devp caches clear deno empties the shared cache behind it.

  It takes vendor/ only when the Deno config asked for one. Go and Composer both use
  that name at a project root for something else entirely, and a repository carrying a
  deno.lock alongside either would otherwise have had its Composer dependencies deleted
  with deno install offered to put them back. The config is parsed rather than searched,
  so a "vendor": true somebody commented out in a deno.jsonc reads as what it is.
  Reference

• finch and Apple's container join the container report and devp caches clear.
  finch is nerdctl inside a Lima VM and forwards system to it verbatim, so it reads and
  clears exactly as nerdctl does. Apple's engine is the odd one: its system df answers
  with a single object rather than a row per resource, it has no system prune, and its
  prune subcommands neither ask a question nor define a -f — so those steps run the
  moment they are typed, and devp caches containers container says so in as many words
  before it lists them. The confirmation is dev-prune's own, and it is still there.
  Reference

• devp config set cache_max_gb default=10 caps every download cache at once,
  without you first having to learn which twenty-nine of them exist. Until now a ceiling
  had to name a manager, which meant the setting only ever covered the caches you had
  already thought about — and the one that has quietly passed 10 GiB is rarely one of
  those. A manager named outright still wins: default=10,npm=4 holds npm to four and
  everything else to ten. Setting a ceiling still deletes nothing; it decides what
  devp caches calls too big, and devp caches clear --over-cap all is still typed by
  hand.

  The first run now suggests it, alongside the adapters, and devp config recommended sets it. It is the first suggestion that is not a yes-or-no, so it is
  the first one that can already be satisfied by a different answer: any ceiling at all
  counts as taken. A machine with npm=4 set by hand is listed as Already set,
  never as outstanding, and devp config recommended leaves the number alone rather
  than replacing the map with its own.
  Reference

• devp stats now says which package manager the space came from. The tool has
  twenty-four adapters and, until now, never told you which of them was earning its keep
  — the lifetime total was one number with nothing behind it. By package manager
  ranks them by what each has given back, with the directory count beside it, so "npm is
  the one costing me" stops being a hunch. It covers pruning only, and says so under
  itself: emptying a cache is not a prune pass, so these figures are not meant to add up
  to the lifetime total above them.

• devp stats also shows how many passes you typed and how many ran unattended.
  How passes start splits the same reclaims across manual, scheduled and
  dashboard, each with its share. All three print even at zero, because a scheduled
  line reading zero passes is how you find out the daemon has never actually run — and
  when it does read zero, the report points you at devp status daemon. Both sections
  are summed from the prune log, so both are bounded by 1.17.0 and both say how many
  earlier passes they could not account for rather than quietly under-reporting.
  devp stats --json carries them as by_manager and by_trigger.
  Reference

Changed

• Every binary in devp trust now shows the version it was built as, so the list
  answers the question people open it with. Three of those files are called some spelling
  of the same word, and until now the only thing telling them apart was a path and a
  digest — which meant "which of these is the old one" could only be answered by
  uninstalling something and seeing what broke. The newest is marked (latest release)
  when a release check has confirmed that is genuinely the newest release, and
  (newest here) when no check has run and it is only the highest version on this
  machine. The two words are different claims and are never swapped.

  The version is read out of each file's own bytes. devp trust does not run the files
  it reports on — one of them is devpw.exe, which is linked for the GUI subsystem, so
  anything that invokes it from a shell waits forever — so every build from 1.17.0 on
  carries its version as a fixed string a reader can find without executing it. Copies
  built before that show not stamped, which is said out loud rather than left blank: a
  gap beside three filled-in rows reads as a failure to look, and it is not.

  devp trust --json gains version and marker on each binaries entry, both null
  where they do not apply.
  Reference

• devp trust now lists every copy of dev-prune on the machine, not just the ones it
  manages. It looks in every directory on PATH and in the install directory of every
  channel it knows about — including the ones that stop being on PATH when a venv
  deactivates or a profile line goes — and prints each copy with the manager that
  installed it, its SHA-256 and the lookup URL for that digest.

  The old report knew about the managed directory and the file that was running, so a
  machine carrying dev-prune, devp and devpw in ~/.cargo/bin as well saw one row
  out of four. That is the wrong count to print under "binaries on this machine", and it
  hid the case the section exists for: several copies, different ages, and only one of
  them the one your antivirus just looked at. Several copies is not a fault — a
  cargo install and an installer run each leave one and they upgrade separately — and
  devp uninstall names the command that removes each. Shims are left out: a .cmd
  wrapper is a text file that runs the real executable, so a digest for it compares
  against nothing. Nothing found is ever executed, only hashed. --json gains a
  channel field per binary.
  Reference

• devp caches now prints devp caches clear <manager> beside each cache, above the
  manager's own command rather than instead of it. The two are not synonyms: what
  dev-prune clears is added to the lifetime total in devp stats, and npm cache clean
  typed into a terminal is invisible to it — so the report a week later was short by
  exactly the space you had reclaimed. The manager's command still gets its own line,
  labelled runs:, because that is what dev-prune executes and hiding it would be worse
  than repeating it. Maven is unchanged and still prints only the manual command: its
  local repository is not a cache, and devp caches clear maven refuses.
  Reference

• devp run --ignore-idle now prints the manual route next to the AI one. The notice
  already pointed at devp skill for anyone still stuck; it now also lists the five
  commands that skill would reach for — devp run --explain, devp status, devp doctor,
  devp config show and devp man — so you can work the problem yourself instead of
  handing your shell to a language model to find out what --explain would have told you.

• auto_discover and auto_hooks now say which arrivals each of them actually covers.
  Their descriptions in devp config read as two vague promises to find things, and
  neither mentioned the other, so there was no way to tell that the Git hooks only ever see
  repositories Git itself creates. auto_hooks now names its three triggers — clone,
  commit, merge — and hands everything else to auto_discover, which now says that it runs
  only on the scheduled pass and finds projects by looking beside the ones you already
  have.

• devp --help is grouped and coloured. Twenty commands as one flat list answered
  "what exists" and nothing else; the front page now sorts them into the five groups the
  manual's contents page already used — register, prune, look, configure, the program
  itself — with the headings and command names coloured wherever the output is a
  terminal. Every command's own --help picks up the same palette. Pipe or redirect it
  and the colour goes away; the grouping stays.

• devp undo and devp install have left the front page. Both still work exactly
  as before — their own --help, devp man undo, devp man install and the
  reference all still answer — but neither earns a
  line in devp --help or a shell completion any more: undo covers ground
  devp restore also covers, and install moves an installation between package
  managers rather than performing one. Renaming or removing a command that shipped in
  1.0.0 is a breaking change, so that waits for 2.x; this release just stops advertising
  them to newcomers.

• The walkthrough's accelerators now take the cautious recommendation too. Holding
  Enter, pressing a, or Shift+Enter used to apply every recommendation except
  allow_manifest_rewrite, on the theory that a held key must not accept a setting
  with a warning attached. In practice that meant the accelerators did not produce the
  recommended setup. They now take it with the rest — its explanation is on the very
  screen those keys are pressed on, it still arrives switched off, and Space on its
  row still declines it. Outside the walkthrough nothing moved: devp config recommended still leaves it alone unless you pass --with-cautious.

For contributors

• The release workflow registers each published digest with VirusTotal. A binary with
  no reputation is what heuristic engines score as suspicious, which is how the 1.5.0 zip
  came to be quarantined; the answer is for every image to be known before the first user
  downloads it, so that devp trust sends people to a report that exists. The job looks
  each digest up and submits only what nothing has seen — including devpw.exe, which
  ships inside the Windows zips and so had no record of its own. It never fails the
  release: same-day detection counts are noise that falls as downloads accumulate, and a
  workflow that gated on them would block every release forever. Skipped with a warning
  when the repository has no VT_API_KEY secret.

Fixed

• The one safety promise on devp's first screen named the wrong command. Both the
  bare-devp banner and the first screen of devp setup ended with "Only what a lockfile
  can rebuild — and devp undo puts back the last run." devp undo reverses an init or
  a link; it has never put a pruned directory back, in any release. The command that
  does is devp restore --last-run, which is what both screens now say.

• devp caches explains the per-repository figure that looked like an arithmetic
  error. A row reading go build cache 2.7 GiB · go is used by 3 of 9 registered repositories · 1.5 GiB each was correct and unreadable: the figure covers both of go's
  caches, and the row it is printed beside is the smaller one. It now says what it summed
  — 1.5 GiB each across its 2 caches — and only where a manager has more than one.

• devp status → [p] can now select the repositories it is showing you. Prune-select
  mode only ever accepted repositories already past the idle threshold, so on a machine
  where you have touched everything recently — the normal case — pressing p armed
  nothing, [Space] did nothing, and a mode that opened empty looked exactly like a mode
  that had failed to open. [Space] now selects any repository with something to reclaim,
  including one you are working in today, and a row it still refuses says why: nothing to
  reclaim, ignored, path missing, or a .devprune.json it could not read. The footer
  counts against what is actually selectable rather than against everything on screen.
  Nothing about what can be deleted changed — lockfile verification runs on every
  selected repository exactly as before and still has no bypass. [a] and [p] continue
  to arm only idle repositories, because [Enter] prunes without asking a second time.

---

Which download do I want?

Most people want none of them. The installers below verify the SHA-256
sidecar, put the binary somewhere already on PATH, and create the devp
alias — three things unzipping an archive does not do.

You are on	Run this
Windows (PowerShell)	iwr -useb https://devprune.vkrishna04.me/install.ps1 | iex
Windows (Command Prompt)	powershell -NoProfile -ExecutionPolicy Bypass -Command "iwr -useb https://devprune.vkrishna04.me/install.ps1 | iex"
macOS / Linux	curl -fsSL https://devprune.vkrishna04.me/install.sh | sh
Python tooling	uv tool install dev-prune==1.17.0 / pipx install dev-prune==1.17.0
Rust, no compile	cargo binstall dev-prune@1.17.0
Rust, from source	cargo install dev-prune --version 1.17.0 (needs Rust 1.88+)

The PyPI packages contain these same binaries rather than downloading one
afterwards, so they work behind a registry mirror and offline. cargo install
is the only channel that compiles on your machine; cargo binstall reaches
for the archives on this page instead.

Full instructions: https://devprune.vkrishna04.me/#install

The assets, then

Take one only if you are packaging dev-prune yourself, air-gapping it, or
pinning it into a container image.

Asset	For
dev-prune-v1.17.0-windows-x64.zip	Windows on Intel/AMD — almost every Windows PC
dev-prune-v1.17.0-windows-arm64.zip	Windows on ARM — Surface Pro X, Snapdragon laptops, Windows in a Mac VM
dev-prune-v1.17.0-windows-x86.zip	32-bit Windows — locked-down corporate images, older industrial machines
dev-prune-v1.17.0-darwin-arm64.tar.gz	Apple Silicon Macs — M1 and later
dev-prune-v1.17.0-darwin-x64.tar.gz	Intel Macs — 2020 and earlier
dev-prune-v1.17.0-linux-x64.tar.gz	Linux on Intel/AMD
dev-prune-v1.17.0-linux-arm64.tar.gz	Linux on ARM — Raspberry Pi 4/5, Graviton, ARM CI runners

Both Linux builds are statically linked against musl, so they run on any
distribution including Alpine, with no glibc floor.

32-bit is published for Windows only. There is no 32-bit Linux, no 32-bit
macOS and no 32-bit ARM build on any platform; the install scripts refuse
rather than guess when they meet one.

There is no .vsix on this page. The VS Code extension has its own
version and its own release cadence, so it ships from its own tags:
the extension's releases.
Install it by name instead — VKrishna04.dev-prune, on the
VS Code Marketplace
and on Open VSX.

Windows: the binaries are not code-signed, and two separate features react
to that.

Windows protected your PC is SmartScreen, and it only challenges files
carrying a Mark of the Web — which your browser attaches to the download and
File Explorer copies onto everything it extracts. Clear the mark on the archive
before extracting and nothing inside it is ever marked:

Unblock-File .\dev-prune-v1.17.0-windows-x64.zip

The installers above already do this for you, on the archive and on both
installed copies.

A refusal with no dialog and no "run anyway" is something else: Smart App
Control, which blocks unsigned executables outright and never looks at the mark.
It is on by default on clean installs of Windows 11 22H2+ and always off on
upgraded ones, which is why the same release runs on one machine and not the
next. Unblock-File does not help, and neither does building from source.
The troubleshooting guide
covers what your options actually are.

Every archive ships a .sha256 sidecar. Check it before you trust it:

sha256sum -c dev-prune-v1.17.0-linux-x64.tar.gz.sha256

(Get-FileHash dev-prune-v1.17.0-windows-x64.zip).Hash -eq (Get-Content dev-prune-v1.17.0-windows-x64.zip.sha256).Split(' ')[0].ToUpper()

An archive's hash stops meaning anything the moment you unpack it, and the
unpacked files are the only ones your antivirus ever looks at. So each Windows
zip also ships a .zip.contents.sha256 listing the digest of every file inside
it — run this in the folder you extracted to, from Git Bash (sha256sum ships
with Git for Windows, and is what reads this format):

sha256sum -c dev-prune-v1.17.0-windows-x64.zip.contents.sha256

dev-prune.exe and devp.exe are one file under two names and share a digest
on purpose, so a scanner builds one reputation record instead of two.
devpw.exe — the console-free build the scheduled task runs — is compiled
separately and legitimately has a different one. devp trust prints the same
three digests for the copies already installed on your machine, so you can
compare them against this file without downloading anything again.

That sidecar proves the file was not altered in transit. It does not prove
where it came from — the same hand that swaps an archive swaps its sidecar.
Every archive on this page is also signed by GitHub's build provenance, which
binds it to this repository, this workflow and the commit it was built from:

gh attestation verify dev-prune-v1.17.0-linux-x64.tar.gz --repo Life-Experimentalist/dev-prune

gh attestation verify dev-prune-v1.17.0-windows-x64.zip --repo Life-Experimentalist/dev-prune

What's Changed

• Thirteen caches devp could not see, a Deno adapter, and two more container engines by @VKrishna04 in #17
• Every binary in devp trust says which version it is by @VKrishna04 in #18
• A cache ceiling that does not need you to name the cache by @VKrishna04 in #19
• devp stats: break the lifetime total down by package manager and by trigger by @VKrishna04 in #20
• Grouped, coloured devp --help; undo and install leave the front page by @VKrishna04 in #21
• The walkthrough's accelerators take the cautious recommendation by @VKrishna04 in #22
• Release 1.17.0 by @VKrishna04 in #23

New Contributors

• @VKrishna04 made their first contribution in #17

Full Changelog: v1.16.0...v1.17.0