---
id: "lib-2026-10-20-six-weeks-of-vibe-coding-and-a-20-minute-mac-boot"
type: "library"
title: "Six weeks of vibe coding and a 20-minute Mac boot"
title_original: "バイブコーディングを6週間続けたら、Mac の起動が20分かかるようになった"
lang: "JA"
org: "Singularity Society"
source_type: "Practitioner post"
date: "2026-10-20"
week: "2026-W43"
url: "https://nosov.ai/library/lib-2026-10-20-six-weeks-of-vibe-coding-and-a-20-minute-mac-boot/"
original_url: "https://zenn.dev/singularity/articles/vibe-coding-mac-boot-20min"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "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_basis: "full-text"
original_minutes: "9"
tags: ["agent operations", "endpoint cost", "failure post", "coding agents"]
---

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

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

Tier 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.

## 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,000: files in /private/tmp 9.5 hours after boot, almost all Claude Code scratch directories
- ~18 min: boot stall with no log lines while macOS cleaned temporary files
- ~600 GB: data written to the SSD per day, against tens of GB for typical use
- 1,100-4,500: node process launches per minute across the system

## 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

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

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

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

A report is a claim, not a fact.

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

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

Original: https://zenn.dev/singularity/articles/vibe-coding-mac-boot-20min