Personal Mac doubles as the shared crew host — disk-capacity troubleshooting

Applies to: any agent hitting No space left on device during multica repo checkout or other repo work on the crew daemon host (Joshuas-MacBook-Pro-2.local, aka joshuas-mbp-2 in multica-daemon-disk-hygiene.md).

The trap

multica repo checkout (or git inside an existing checkout) fails partway through with No space left on device. The obvious next move — find and delete stray checkouts, task workdirs, or caches until the number adds up — will not add up. This host is not a dedicated CI box; it is simultaneously Josh's personal Mac, with Photos, Mail, Messages, Dropbox, a second macOS user account (lockharts), and iCloud/CloudDocs sync all living on the same volume as every Multica agent's task workdirs.

First move: check the right volume

df -h / /System/Volumes/Data

Check /System/Volumes/Data, not / — on this host's APFS layout the data volume (where ~ actually lives) is the one that fills up; /'s own usage stays low and uninformative.

Why the numbers won't add up from an agent's view

A large majority of used space is TCC-protected personal data that no agent process can see or measure: du/find return Operation not permitted on Photos-, Mail-, Messages-, and CloudDocs-adjacent paths under ~/Library, even though ls -ld shows them owned by joshualockhart — this is a Full Disk Access / TCC restriction, not a Unix permission gap an agent can work around. A second real user account, lockharts, also has its own protected home directory outside any agent's reach.

Dave's investigation on OBJ-3160 (comment 160e6d51-48f6-4a1a-afcf-4009723ba54e, 2026-09-01) quantified this on a disk at 906GB/932GB used: every path an agent process could measure — ~/Library (visible portion), ~/code (legitimate client repos), ~/Dropbox, ~/.rvm, ~/.cache, tooling caches — summed to only ~176GB. Six confirmed stray, non-isolated enkidu checkouts (a real hygiene issue, since fixed) added another ~6GB. That still left ~730GB unaccounted for and unmeasurable from an agent's context — consistent with it living in the TCC-walled Photos/Mail/Messages/iCloud data that makes this a personal-use Mac, not a dedicated agent box.

Don't spend a full investigation cycle trying to account for usage down to the byte. A du sweep of everything an agent can read will always fall far short of the total, by design — that shortfall is the TCC wall, not a bug in the sweep.

What this is not

This is a different root cause from the task-dir GC leak in multica-daemon-disk-hygiene.md, even though both present identically (No space left on device during a checkout) on the same host:

• The GC-leak doc's cause is agent-created and agent-fixable: task workdirs pinned on disk because native GC gates reclamation on the linked issue reaching done server-side. That has a durable fix (7-day TTL config, a fail-closed backstop reaper) tracked in that doc.
• This doc's cause is structural and not agent-fixable: personal data sharing a volume with the agent fleet, with no reserved headroom or quota between the two. No amount of task-dir cleanup resolves it, and it can recur immediately after any cleanup pass if personal-data usage is what's actually growing.

Check both — a No space left on device symptom on this host can be either, or both at once — but don't assume clearing GC-eligible task dirs is sufficient just because it's the fixable half.

What to do

1. Run df -h /System/Volumes/Data first, per above.
2. If free space is critically low, a retry of the failed operation may succeed on its own if another agent's cleanup or native GC has landed in the meantime — this host's free space is not static. Confirmed directly on this issue (OBJ-3163, 2026-09-01): a multica repo checkout failed with 581MiB free, and a second attempt minutes later succeeded once free space had risen to 6.1GiB from a concurrent cleanup pass. One retry is reasonable; don't loop indefinitely on it.
3. If it's still blocked after a retry, don't re-run the stray-checkout investigation from scratch — it has already been done (see Dave's comment above) and reliably falls ~700GB short of explaining the total. Report the blocker with the current df reading and route to a human (via Maggie) for a capacity decision: freeing personal-data space, or relocating the agent fleet's workdir root off this machine. Freeing GC-eligible task dirs (per multica-daemon-disk-hygiene.md) is worth doing regardless, but treat it as routine hygiene, not a fix for the structural shortfall.

Related

• Multica Daemon Disk Hygiene — the other, agent-fixable root cause behind the same symptom: task-dir GC gated on issue status
• Multica Runtime Identity (daemon.id hijack) — same host, a different "every liveness signal looks fine" failure mode
• OBJ-3160 — Dave's diagnosis (comment 160e6d51-48f6-4a1a-afcf-4009723ba54e) that this doc compiles
• OBJ-3163 — this doc's own tracking issue; confirmed the failure and the retry-succeeds-after-cleanup behavior live while writing it

---

Last updated: 2026-09-01