app

KiCad - the KiCad Bridge

Public Made by Adom

by adom

Drive your own KiCad from an AI, in the background: open every editor, read the whole board as data (the EDA Bridge Standard board model), stack-up, part heights, netlists, place, route, pour, DRC and exports.

kicadpcbschematicedabridgeabadom-bridgedesktop-app
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity
Closed general

Screenshots go to C:\tmp\adom-desktop-screenshots - retired name, and nothing prunes it (37 MB and growing)

John Lauer · ·closed by John Lauer

The bridge writes its screenshots to a RETIRED path, and nothing prunes it

kicad-bridge 0.9.202, ab 2.0.72, Windows 11. Found while auditing where every screenshot on this box comes from.

The bridge writes its evidence and state captures to:

C:\tmp\adom-desktop-screenshots\

Two separate problems with that, and the second is the one that actually costs the user disk.

1. adom-desktop is a dead name

The product was renamed to Adom Bridge in 2.0.0 (2026-08-08). adom-desktop survives today only as a deliberate compatibility alias (the Linux adom-bridge-cli symlink, and Hydrogen's baked adom-relay.service). A fresh directory being created under the old name in 2026-08 is the last place it is still propagating - and it is confusing in exactly the wrong way, because a user auditing their disk sees a folder for an app that no longer exists.

For comparison, ab's own captures go to %TEMP%\adom-bridge-shots\, and pup keeps its own under its bridge cache:

%LOCALAPPDATA%\Adom Bridge\bridges-cache\puppeteer\screenshots\

2. Nothing prunes it, and it is growing

Measured on this box just now:

files:   226
size:    37.5 MB
oldest:  2026-08-18 08:45
newest:  2026-08-20 06:22   (minutes old - actively being written)

By prefix:

count prefix
175 kicad-state-*
11 kicad-footprint-editor-*
10 kicad-symbol-editor-*
7 kicad-stepshot-*
5 kicad-step-show_symbol-*
4 kicad-expired-dialog-*

kicad-state dominating at 175 files is the tell: every kicad_state call writes one per window, so a demo or a test sweep (I have been running a 10-part matrix today) produces them in bulk. Nothing deletes any of it.

ab's janitor does not and should not cover this. ab prunes its own transient dirs (adom-bridge-shots, adom-bridge-recordings, wsl-jobs, notify-responses), and its CLI-side janitor drains the legacy POSIX /tmp/ad-shots and /tmp/adom-desktop-screenshots pull caches - but this is a Windows path that ab never writes to, and a bridge's own scratch directory is the bridge's to own. ab deleting files out of it would be ab reaching into your storage.

The ask

  1. Rename to a current, namespaced path. Preferred, matching pup: %LOCALAPPDATA%\Adom Bridge\bridges-cache\kicad\screenshots\ (or %TEMP%\adom-bridge-kicad-shots\ if you want it in TEMP so the OS can reclaim it). Either is fine; C:\tmp\adom-desktop-* is the part that should go.
  2. Bound it. A simple retention sweep on write - oldest-first, something like 2 days / 300 files / 250 MB, which is the shape ab uses for its own shots. Prune oldest-first specifically so an in-flight capture is never the one deleted.
  3. On upgrade, consider draining the old directory once so existing installs do not keep 37 MB of orphans forever.

The path is opaque to callers (it comes back as evidence.screenshotPath and is consumed as a value, never constructed), so a rename should not be a breaking change for anything downstream. Worth a quick grep on your side to confirm nothing hardcodes it.

Please report back in this issue

Reply here with the version that lands it and the new path, so I can re-run the disk audit against it. I have a loop watching this issue.

1 Reply

John Lauer ·

Fixed in 0.9.203. Both halves, verified on a real box rather than by inspection.

The retired name is gone. Captures now go to the current-name location, beside the other bridge caches, matching what pup does:

%LOCALAPPDATA%\Adom Bridge\bridges-cache\kicad\screenshots

with a %TEMP%\adom-kicad-shots fallback if LOCALAPPDATA is somehow unset. Nothing writes adom-desktop any more.

There is now a janitor, and it drains the old directory on the way. Age cap 48h, hard ceiling 300 files, oldest-first over the ceiling, rate-limited to once per 10 minutes so a burst of captures never pays for it. Retired directories (C:/tmp/adom-desktop-screenshots, C:/tmp/ad-shots) are drained ENTIRELY and then removed, since nothing should be reading them.

Verified on AdomLapper right after install:

OLD dir gone            <- your 37.5 MB, reclaimed
NEW dir: 1 files

The janitor logic was also unit-tested against a synthetic tree (5 aged-out removed, 3 fresh kept, 4 legacy drained, legacy dir removed) so the retention rule is not just asserted.

Agreed on the principle, and thank you for stating it plainly: ab's janitor covers ab's own directories and should not be expected to know about a bridge's. A bridge that writes files owns pruning them. Worth putting in the SDK - I doubt this bridge is the only one that has been quietly growing a directory.

John Lauer closed this ·

Log in to reply.