The three usual causes, in order of likelihood on macOS:
devdoctor scan --provider time-machine-local-snapshots
devdoctor clean --execute --provider time-machine-local-snapshots
The end-of-run summary says so explicitly when it detects the measured change lagging the estimate for this reason. Deleting a snapshot needs administrator rights: when tmutil refuses, the entry and the run are marked failed (never “ok”), and the summary tells you to run sudo tmutil deletelocalsnapshots / in Terminal, which deletes every local snapshot on the startup disk.Docker.raw file on your Mac shrinks afterwards, not instantly. Judge with docker system df, then give it time or force it with docker run --privileged --pid=host docker/desktop-reclaim-space. Docker may stop answering for a few minutes while it compacts. Deleting files inside a running container frees nothing on the host; only removing images, containers, volumes or build cache does.· print guidance instead of running anything — re-read the summary's estimated-vs-planned numbers.On Linux, cause 1 does not apply; check 2 and 3.
A fourth figure appears only for sparse files: apparent size, the file's length. Docker Desktop's Docker.raw is 80 GB long by default and occupies only what Docker has written, often less than half. DevDoctor counts what it occupies, because that is what your disk gives up; Finder and ls show the length. scan prints a Sparse: note under the table for such an entry, and --json carries apparent_bytes. The difference was never on your disk, so it is described and never offered as reclaimable.
Some things cannot be measured without doing the destructive thing first. DevDoctor offers the entry with unknown size rather than hiding it — the plan still shows the exact command, and you decide.
Every skip carries a reason: dangerous without --allow-dangerous, advice-only entries, covered entries, entries that changed after the scan, and unavailable providers.
uv cache clean hang or fail when I run DevDoctor with uv run?uv run and uvx hold the uv cache lock while the program they started is running, so a uv cache clean started from inside waits for that lock forever. DevDoctor notices when it is running under uv (both export UV=<path to uv> to their child) and passes --force; the plan shows the exact command, and a scan says so in its diagnostics. It is safe: the running environment keeps its own copies of its packages. A devdoctor installed with uv tool install runs on its own and needs no override.
Only for seeing everything. Unreadable paths land in the report's diagnostics and are excluded from totals. On macOS, grant Full Disk Access (System Settings › Privacy & Security) if the total looks too small.
No. Scanning, cleanup, and the web UI are all local; the landing page ships no cookies or analytics.
Codex and Claude Code transcripts are your history, not a cache, so the agent-sessions providers never offer them wholesale. Sessions are grouped into age buckets (under 30 days, 30 to 90, 90 to 180, 180 to 365, over a year). A bucket untouched for the retention floor, 90 days by default, is offered one session at a time; anything younger is sized and shown and cannot be selected, even with --allow-dangerous. devdoctor clean --provider codex-sessions --older-than 90d is the whole operation. DEVDOCTOR_SESSION_RETENTION_DAYS raises or lowers the floor, never below 30. OpenCode keeps everything in one SQLite database: DevDoctor counts its sessions by age read-only and never edits it; delete old sessions in the app, then VACUUM.
Snapshots (snapshot / diff) and the cleanup history log (history) share one local store used by both the CLI and the web UI.
Next: Tutorial · Safety model · All docs