v1.16.0

Added

• devp caches --volume V: reports only the caches sitting on one drive, and the
  unfiltered report now ends with a By drive line splitting the total the same way.
  On a machine whose projects live on a second disk, "22 GiB of caches" is not the
  figure that decides anything — the two gigabytes on the drive that is full is, and
  until now you had to read twelve absolute paths to find it. --drive is the same
  flag; both take a drive (V:, V:\, or the bare letter V), a mount point
  (/mnt/data, /Volumes/Work), or any path on the one you mean, so --volume . is
  the drive you are standing on. In --json, every cache row gains a volume key so a
  consumer can group by drive without deriving a mount table from path.

  The narrowing happens last, after every verdict, so it changes what you see and never
  what a figure means: a cache_max_gb cap still weighs a manager's whole footprint
  wherever it is, and a cache no registered repository uses does not become unused just
  because the repositories that use it live on another drive. Container engines are left
  out of a filtered report entirely — an engine reports its disk from inside a VM image
  that has no path on this filesystem, so there is no honest drive to file it under, and
  the JSON document omits containers rather than emitting an empty list that would
  claim none are installed. devp caches docker still has that number.

  --volume with clear, docker or containers is a usage error rather than a flag
  that looks accepted and does nothing: the clear commands empty a manager wherever it
  is, and a clear that had silently ignored the drive you handed it would be the worst
  possible way to find that out.

• a finishes the configurator in one keystroke. devp config wizard takes every
  remaining safe recommendation and jumps straight to the summary, which still needs its
  own Enter before anything is written. It applies exactly what holding Enter down
  would have applied — allow_manifest_rewrite is left off by both, because it can edit
  a file Git tracks and that stays a deliberate Space. Shift+Enter does the same
  thing on terminals that report the modifier; a is the spelling that works
  everywhere, so a is the one the footer names. The first screen now says so too:
  hold Enter and the whole setup configures itself.

• devp trust now ends with every binary it owns and the SHA-256 of each, the one
  you are running marked and listed first, each with a VirusTotal lookup URL for that
  exact digest. When a scanner objects to dev-prune, the file it objected to is the one
  on your disk — not the asset on a release page — and until now there was no way to ask
  the tool which bytes those were. The digests are computed locally and the URLs are
  printed rather than fetched: nothing is uploaded anywhere, and a digest the service has
  never seen returns not found, which means unscanned rather than clean. On Windows
  dev-prune.exe and devp.exe share a digest on purpose — one file under two names, so
  a scanner builds one reputation record instead of two — and devpw.exe, the
  console-free build the scheduled task runs, is a separate build target that legitimately
  differs. devp trust --json carries the same facts under a new binaries array with
  sha256 as a field of its own, so a check can compare it against a published checksum
  without parsing a sentence.

• Every Windows release now ships a .zip.contents.sha256 listing the digest of each
  file inside the archive, in sha256sum format — sha256sum -c in the folder you
  extracted to verifies all three at once. An archive's hash stops meaning anything the
  moment you unpack it, and the unpacked files are the only ones an antivirus ever looks
  at, so there was previously no published answer to "is the devpw.exe on my disk the
  one you built?". The same digests come out of devp trust, which is the side of the
  comparison you actually control.

Changed

• The banner now says what the tool is. Under the art, two lines: every dependency
  directory on the machine in one command, and the promise that only what a lockfile can
  rebuild is ever deleted — with devp undo behind that. The screen every interactive
  command opens with said the name, the version and nothing else, so the first thing a
  new user saw answered neither "what does this do beyond node_modules" nor "what
  stops it deleting my work". The version now sits at the right edge under the art
  instead of trailing it, and PRUNE carries the weight DEV does not.

Fixed

• The configurator no longer skips the settings above the cursor. After an upgrade
  added a setting, devp config wizard opened on that setting — halfway down the
  list. But the walk only moves downwards and leaves through the finish line at the
  bottom, so holding Enter from there never offered a single row above it. Anyone
  configuring the tool the way its own footer suggests was configuring a suffix of it.
  The cursor now starts at the top and the walk reaches everything; the new setting is
  still marked NEW when it comes around.

• The AI skill now stays current on machines that turned auto-setup off. dev-prune
  exports SKILL.md — the file Claude Code and the other agents read to learn its flags
  — and rewrites it after every upgrade. That refresh rode along with the automatic
  setup pass, so turning setup off (devp config set auto_setup false, or
  DEV_PRUNE_NO_AUTO_SETUP) also froze the skill at whichever version installed it: the
  agent went on describing flags that had been removed two releases ago, confidently,
  because nothing told it otherwise. An upgrade now refreshes the copies that are
  already on disk regardless of that setting, and creates none that were not — a machine
  that never wanted an exported skill still does not get one. devp doctor continues to
  report a stale copy, and devp skill still rewrites it on demand.

---

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.16.0 / pipx install dev-prune==1.16.0
Rust, no compile	cargo binstall dev-prune@1.16.0
Rust, from source	cargo install dev-prune --version 1.16.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.16.0-windows-x64.zip	Windows on Intel/AMD — almost every Windows PC
dev-prune-v1.16.0-windows-arm64.zip	Windows on ARM — Surface Pro X, Snapdragon laptops, Windows in a Mac VM
dev-prune-v1.16.0-windows-x86.zip	32-bit Windows — locked-down corporate images, older industrial machines
dev-prune-v1.16.0-darwin-arm64.tar.gz	Apple Silicon Macs — M1 and later
dev-prune-v1.16.0-darwin-x64.tar.gz	Intel Macs — 2020 and earlier
dev-prune-v1.16.0-linux-x64.tar.gz	Linux on Intel/AMD
dev-prune-v1.16.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.16.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.16.0-linux-x64.tar.gz.sha256

(Get-FileHash dev-prune-v1.16.0-windows-x64.zip).Hash -eq (Get-Content dev-prune-v1.16.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.16.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.16.0-linux-x64.tar.gz --repo Life-Experimentalist/dev-prune

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

Full Changelog: v1.15.0...v1.16.0