v1.23.0

Added

• pycache joins the Python group as a regular adapter (on by default): it deletes
  __pycache__ by name alone, since CPython owns that name unconditionally, and deletes
  .pytest_cache, .mypy_cache and .ruff_cache only when a CACHEDIR.TAG file inside
  proves the tool wrote it, per the cache directory tagging
  spec. It never touches .hypothesis (holds regression
  examples pytest cannot regenerate on its own), and never .tox or .nox (environments,
  not caches). Verification requires at least one .py file anywhere in the repository,
  so there is always something to regenerate the bytecode and tool caches from. That
  makes thirty-six adapters.

• devp status reports a Tools line for the output graphify and understand-anything
  leave behind (graphify-out/ and .understand-anything/), because both can grow
  into gigabytes and neither has a lockfile to prove it is safe to delete: rebuilding
  either means re-running the tool's own extraction passes, LLM calls included. The
  interactive dashboard's header and the plain-table view both show the size next to
  everything else, and --json carries it as a tools array on each repository entry.
  It is report-only: never counted in the reclaimable total, and never a candidate for
  devp run.

• devp status opens an inspector pane beside the table on terminals at least 110
  columns wide: the selected repository's per-directory sizes, root-commit identity,
  idle window, last prune, lifetime space saved and detected adapters, all in one
  place instead of behind devp doctor <path>. It also draws a sparkline of the
  repository's commits over the last 26 weeks and lists the five largest entries inside
  its bloat directories, both read in the background so moving the selection never waits
  on a large node_modules. A narrower terminal with at least 34 rows puts the pane
  below the table instead, and Tab hides and shows it.

• devp scores (the same report as devp history --scores) ranks your all-time
  largest single-repository cleanups and largest whole passes, read from the same pass
  log devp history prints, with medals on the top three of each. --json emits it
  as a document with "command": "history --scores".

• The registry heals itself. devp status, devp run and devp doctor now
  resolve registry entries whose directory is gone instead of warning about them
  forever. A repository
  that moved into a sibling Archive/-style directory, or anywhere else its root-commit
  identity proves it is the same repository, keeps its lifetime statistics under the new
  path. An entry for a deleted AI-agent worktree (.claude/worktrees/,
  .cursor/worktrees/ and kin) is dropped outright, because the session that creates
  one deletes it when it ends. Nothing is merged on a shared directory name alone, so
  an entry whose drive is merely unplugged stays put until the drive returns.

• devp skill --prompt workspace (or --prompt agent) prints just that onboarding
  prompt, with no header or code fence around it, so you can pipe it or paste it
  without trimming. Add --copy and it goes straight to the clipboard instead.
  devp skill --rules-file <path> writes the same marked rules block --agent
  uses into any file you name inside the repository, for an editor --agent does not
  list or one that reads a renamed file; a re-run replaces the block and leaves the
  rest of the file alone. See devp skill in the CLI
  reference.

Changed

• i in devp status asks before it changes anything. A small dialog names the
  repository and what will happen; y or Enter confirms and any other key backs out.
  A stray keypress used to rewrite .devprune.json on whichever row was highlighted.

• devp update --install and the auto-update also replace the copies cargo put on
  PATH. The scheduled pass runs the managed copy, and a copy only ever replaced itself
  and the managed one, so devp typed from ~/.cargo/bin kept answering with the
  release that cargo binstall installed, however many scheduled passes had updated
  since. The dev-prune and devp files in cargo's bin directory now move forward with
  the managed copy, unless they are already the same release or newer (a cargo install --path . development build is never downgraded). Cargo's own record of the installed
  version is not touched, and the update says which command brings it forward.

• devp doctor names the upgrade command for a stale copy, not only the uninstall
  one. A copy on an older release is usually one you still want, on the current
  release, and "remove with cargo uninstall dev-prune" pointed at deleting the binary
  you type. The line now reads, for example, "upgrade with cargo binstall dev-prune --force or remove with cargo uninstall dev-prune".

• Windows binaries no longer need the Visual C++ runtime. They link the C runtime
  statically, so the release zip, the install script, Scoop, npm, PyPI and WinGet all
  run on a clean Windows install instead of failing to start with a missing
  VCRUNTIME140.dll. cargo install
  from crates.io still compiles against the dynamic runtime, which any machine with the
  MSVC toolchain already has.

Fixed

• A pass that found nothing eligible to prune, or stopped early on a lockfile
  verification failure, skipped the auto-update check entirely, so an unattended
  machine whose repositories were all clean or all active could stay on an old release
  indefinitely. The check now runs at the end of every pass regardless of what the
  pass found, with one deliberate exception: a --json pass stays out of it, because
  that mode's stdout is a single machine-readable document and nothing else.

• The windowless devpw.exe twin the Windows scheduled task runs is now refreshed
  when it is stale against the running binary, so an upgrade no longer leaves the
  scheduled task executing the previous version. And when the twin is missing and the
  console binary runs the task instead, it detaches from its console immediately,
  shortening the window flash.

• DEV_PRUNE_NO_TUI now keeps every full-screen view closed, as documented. Only the
  config wizard read it, so devp status and the devp run selector still opened
  whenever both ends looked like a terminal, and an AI agent holding a pseudo-terminal
  landed in a keypress loop it had no way to leave. Set the variable and both print
  their plain output instead.

• -y on devp trust --fix-ownership works in either position. devp -y trust --fix-ownership parsed the flag and then asked anyway, and devp trust --fix-ownership -y was a usage error.

• devp restore --last-run puts a Go vendor/ directory back. Restore chose between
  go mod vendor and go mod download by checking whether vendor/ existed, but the
  prune had just deleted it, so a vendored repository always got go mod download,
  which exits successfully without recreating anything, and the pass reported
  "restored" over a directory that was still gone. It now rebuilds what the prune
  recorded, and reports a failure unless vendor/ exists afterwards.

• Pressing i on a repository ignored through the older ignore.devprune.json marker
  took two presses to un-ignore it. The first wrote "ignore": true and deleted the
  marker, so the repository stayed ignored; it is now offered "stop ignoring" straight
  away, and confirming clears both.

• In devp status, after sorting, filtering or searching, the highlighted row's path
  could keep the colour meant for an unhighlighted one while a different row got the
  white text meant for the highlight, which is unreadable on a light terminal theme.
  The highlight is now matched by its position on screen.

• devp run --help lists deno and dotnet_build among the --only and --skip
  names, devp caches --help covers every manager the report sizes, and the sample
  output throughout the docs says MiB and GiB, which is what dev-prune prints.

• When a .devprune.json cannot be read, devp run, devp doctor and devp config
  now suggest devp config project <PATH> --update to reset it. The hint used to say
  devp config <PATH> --update, which is a usage error, so following the advice printed
  only clap's complaint.

For contributors

• devp uninstall and devp update now recognise a development build anywhere under
  target/, including target/<triple>/release and cargo-llvm-cov's
  target/llvm-cov-target/debug. Before, an uninstall run from one of those deleted the
  binary it was running from, so cargo llvm-cov failed the uninstall tests.

---

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

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

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

Full Changelog: v1.22.0...v1.23.0