Build residue: target/release/plugins 32.7 GB never cleared, 120 installers kept in bundle, target/debug 42 GB idle since Aug 31

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

Found while freeing disk on AdomLapper (2026-09-05, the drive was at 0.5 GB free): C:\Github\adom-bridge\src-tauri\target is 103 GB, and most of it is accumulation rather than what a build needs.

target\release, 60.8 GB:

plugins\ 32.7 GB. Not cargo output; whatever the build stages there per plugin/bridge is never cleared between builds.
build\ 15.5 GB of build-script outputs (7.7 GB of it is 1,189 .pdb files).
deps\ 10.1 GB, the real compiled dependency set.
bundle\ 2.1 GB holding 120 installers, one per build ever made.

target\debug, 42.4 GB, last touched Aug 31.

A from-scratch release build of ab should recreate roughly the deps + build share (~25 GB), so clearing the directory costs one full rebuild and returns ~80 GB net. Suggestions for the ab build script so it does not regrow: clear plugins\ before staging, keep only the newest one or two installers in bundle\, and wipe target\debug when it is older than a week. Nothing of ab's was deleted; the numbers are from a size pass only. Hydrogen's task got the installer pruning today for the same reason (its release dir had 11 GB of incremental cache and 12 installers after one day).

1 Reply

John Lauer · 2mo ago

Measured and cleared on AdomLapper; the 32.7 GB was not build output.

target/release/plugins/puppeteer held the puppeteer bridge's RUNTIME data written next to its staged server.js: 30 GB of Chrome profiles (257 of them), 2.4 GB of screenshots, 2 GB of recordings. It was dead weight: the newest profile dated 2026-06-15, from the era when dev builds ran pup from the staging dir; the live pup runs from bridges-cache (2.0.408, 91 MB total). Removed. Also removed: target/debug (37 GB, idle since Sep 2), 116 of 120 installers in bundle/nsis (canonical copies live in scripts/releases, now capped at the newest 10 versions). Net: the drive went from 118 GB free (after your pass) to 196 GB.

So it does not regrow: scripts/prune-build-residue.sh (new) removes bridge runtime data staged into the build tree, keeps the newest 4 installers, wipes target/debug when idle over 7 days and caps the ship archives; release-publish.sh calls it first, and CLAUDE.md now says a bridge's data belongs under %LOCALAPPDATA%\Adom Bridge, never beside its code. The build/ .pdb share (8 GB, 1058 files) is genuine build-script debuginfo for the dependency set; left alone, since trimming it means a profile change with a full rebuild for one-time savings.

Follow-up for the bridge side (pup-bridge, filing separately): pup writes profiles/screenshots/recordings relative to its install dir, so the same growth would recur inside bridges-cache on a busy box; ab will hand every bridge an ADOM_BRIDGE_DATA_DIR and the pup data should move there with its own retention.

John Lauer closed this · 2mo ago