B JA Singularity Society·Practitioner post·

Six weeks of vibe coding and a 20-minute Mac boot

バイブコーディングを6週間続けたら、Mac の起動が20分かかるようになった

B · Useful, limited A solo developer's careful read-only diagnosis of one Mac, with logs, counts and SMART data; useful and well documented, but a single machine and a root cause the author says is still unverified.

Summary based on the full text·Original: about 9 minutes to read

In short

A Zenn post (20 October 2026) by Isamu, a developer who runs about ten products in parallel through many Claude Code sessions. After a crash his Mac took around 20 minutes to boot. He had Claude Code diagnose the machine under a read-only rule and traced the likely cause to scratch directories where agents cloned whole repositories and ran yarn install daily: macOS deletes /private/tmp at boot, and boot waits for that deletion. Memory and SSD wear were fine; daily sluggishness came from saturated CPU.

Key numbers

  • ~990,000files in /private/tmp 9.5 hours after boot, almost all Claude Code scratch directories
  • ~18 minboot stall with no log lines while macOS cleaned temporary files
  • ~600 GBdata written to the SSD per day, against tens of GB for typical use
  • 1,100-4,500node process launches per minute across the system

As reported by the source.

Read the original on zenn.dev

Japanese·Web page·opens zenn.dev

What it reports

  • No logs for the ~18-minute stall: it occurs before logd starts. A force-reset diagnostic file showed only launchd waiting on dirhelper, which had used over 150 s of kernel CPU, the signature of mass file deletion.
  • 9.5 hours after boot /private/tmp held about 990,000 files; per-project scratch directories held about 470,000, 270,000 and 200,000, mostly node_modules. The previous uptime was six weeks.
  • The agent-clone habit was a safety rule: dependency updates ran in fresh clones so agents would not touch the working copy.
  • The first boot was likely mid-deletion when the author forced it off after about 12 minutes; the forced reset did not speed anything up.
  • Memory: about 47 GB in use, no compression or swap in 9.5 hours. SSD: 6% wear, 251 TB written, 9,859 power-on hours, but about 600 GB written per day.
  • Load average 26-28, above core count. Node launched 1,100-4,500 times a minute; one dev server spawned about 1,800 child processes in 11 seconds. Spotlight had indexed about 2.37 million .js files because .metadata_never_index only works at volume root.
  • The agent's first report was wrong: it counted resident tmux processes as repeated launches. The author asks agents to separate confirmed facts from hypotheses.

How they got it

Read-only investigation by Claude Code on the author's own machine: boot timestamps, macOS diagnostic reports, file counts, SMART data via smartctl, kernel and syspolicyd log counts, and a small C program that polled the process list to catch short-lived processes. The author cross-checked claims against source code.

Limits

  • Single machine, single workload. The deleted paths are inferred; the snapshot does not record them.
  • The fix (clean scratch, then reboot) has not yet been tested; the author plans to measure it.
  • Some causes remain open, such as why the dev server's child count varied from 1,800 to 33 per ten seconds.

Why it matters for companies

Parallel coding agents create infrastructure load that sits outside normal monitoring: millions of temporary files, heavy SSD writes and CPU saturation on developer machines. IT teams provisioning laptops for agent-heavy engineers should budget CPU cores ahead of memory, set scratch-cleanup policies and expect boot and indexing issues. The read-only diagnostic rule and the fact-versus-hypothesis split are cheap controls worth copying when agents investigate production or endpoint problems.

Key passages in translation

Japanese original

調べたのは Claude Code です。条件を一つだけ付けました。読み取りだけで診断すること。

English translation

It was Claude Code that investigated. I set one condition: diagnose using reads only.

Japanese original

報告は主張であって、事実ではありません。

English translation

A report is a claim, not a fact.

Japanese original

いちばん怪しいのは、僕が AI に、安全のために毎日のように clone させていたリポジトリの残骸でした。

English translation

The prime suspect was the leftovers of repositories I had the AI clone almost every day, for safety.

Summary based on the full text. Read the original for the full argument and data.Read the original on zenn.dev

Tags

Same week

All of Week 43