v1.20.0

Added

• Adapter idle windows now show up in the report. A repository idle past
  idle_days whose target/ still waits on build_idle_days (or an
  adapter_idle_days entry) used to hold that adapter in silence — the node_modules
  row appeared, the target/ row simply didn't, and nothing said why. Now devp run
  prints one Not examined (adapter idle window: N days) line per held adapter,
  devp run --explain and devp doctor <repo> name the window and the
  devp --ignore-idle run override, and --json carries it as a new
  skipped_adapter_window status. One reading note for scripts: in
  devp status --json, a repository held only by such windows now reports the lowest
  unmet window as its idle_days — the threshold it is actually held to — rather
  than the configured setting.

Changed

• A registered folder that lost its .git no longer fails every scheduled pass.
  Delete and re-clone a repository by hand, or git worktree prune a registered
  worktree, and the leftover entry used to count as a blocking error — exit 1 on
  every devp run until you went looking for why. It is now reported as what it is, a
  stale registry entry: the pass names the path, hints devp unlink <path>, exits
  0, and --json tags the row not_a_repo. If your automation alerts on devp run's
  exit code, note the change: this situation was exit 1 before 1.20.0 and is exit 0
  now. (devp unlink --missing deliberately does not clear these — the directory still
  exists; only its .git is gone.)
• The scheduled prune no longer skips laptops on battery. The Windows task is now
  registered to start on battery power, keep running if the charger is pulled, and
  fire as soon as the machine wakes if it slept through the scheduled time
  (StartWhenAvailable). Existing installations are repaired in place: the next run
  of any devp command that checks the daemon rewrites the task's power settings
  without moving its schedule. A task dev-prune cannot rewrite is reported by
  devp doctor instead of silently left strict.
• A failed update check retries the next day, not next week. When the release
  check cannot reach GitHub — captive portal, proxy, flaky hotel Wi-Fi — the failure
  used to consume the whole update_check_interval, so one bad morning meant a week
  of not hearing about a new release. A failed check is now retried after a day.

---

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

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

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

Full Changelog: v1.19.0...v1.20.0