[Bug] macOS: Claude Code agents spawn with cwd=/ each session pins a CPU core on a full-filesystem ripgrep scan

[alexandernacho]

Describe the bug

On macOS, Buzz spawns Claude Code agent sessions with no working directory set, so each one inherits launchd's cwd of /. Claude Code then kicks off its file-index scan against the filesystem root:

rg --files --hidden /

The rg child blocks writing into a full pipe while the claude (node) parent pegs a full CPU core consuming the stream. The walk never usefully completes, so the session never gets to real work — it just burns a core for as long as it lives.

Buzz keeps adding sessions while it's open, so the cost is cumulative: on a 14-core M4 Max I had 3 cores permanently pinned within ~6 minutes of launching the app, with audible sustained fan noise.

Evidence

Three claude processes, each having spent ~98% of its entire lifetime at ~99% CPU:

  PID  PPID      TIME  %CPU ELAPSED COMM
 7872     1   7:57.24  99.0   08:08 claude
 8007     1   7:57.16  98.5   08:04 claude
20482     1   5:44.67  99.5   05:49 claude

Every one of them has cwd /:

$ lsof -a -p 7872 -d cwd
node  7872  <user>  cwd  DIR  1,16  704  2  /

Each has an rg child scanning root, which has burned only 9–16 seconds of CPU — i.e. it is blocked, not working, while the parent spins:

 8327  7872   0:16.50   0.0  rg --files --hidden /
 8328  8007   0:09.35   0.0  rg --files --hidden /
26639 20482   0:14.36   0.0  rg --files --hidden /

Attribution. The spawned processes show ppid 1 (Buzz detaches them), so the parent link isn't visible in the process tree. The correlation is nonetheless consistent:

• Start order tracks the Buzz launch. In a single ps snapshot: buzz-desktop elapsed 06:01, then claude at 05:59 (+2s) and 05:55 (+6s). PID order (7749 → 7872 → 8007) matches. A third appeared ~2m20s later.
• Claude Code keys its session cache by cwd. The directory ~/Library/Caches/claude-cli-nodejs/- (the encoding for cwd /) was created 2 minutes after ~/.buzz was created on install — so this has occurred on every Buzz run since install, not as a one-off.
• Killing the sessions and quitting Buzz returned the machine to idle; no root-cwd claude process has appeared since.

I have not identified the exact spawn site in the Buzz source. One possible lead: buzz-desktop contains the error string cannot resolve home directory for nest, which would be consistent with nest-path resolution failing and the spawn falling back to /. That is a guess, not a diagnosis.

Steps to reproduce

1. Have Claude Code configured as the harness on macOS, with a Buzz nest at ~/.buzz.
2. Launch Buzz.app.
3. Within a few seconds, run:

   for p in $(pgrep -x claude); do
     echo "PID $p cwd=$(lsof -a -p $p -d cwd 2>/dev/null | tail -1 | awk '{print $NF}')"
   done

4. Observe one or more sessions reporting cwd=/, each with an rg --files --hidden / child and a claude parent at ~100% CPU.

Occurred across two separate Buzz runs on the same machine (2 sessions the first time, 3 the second).

Expected behavior

Agent sessions should be spawned with an explicit working directory — the nest (~/.buzz) or the relevant project directory — never inheriting /. Spawning a coding agent at filesystem root makes it index the entire disk before it can do anything.

If nest-path resolution fails, failing loudly would be much better than silently falling back to root.

Version and platform

• Buzz version: 0.4.26
• OS: macOS 15.7.2 (24G325), Apple M4 Max, 14 cores
• Harness: Claude Code 2.1.220, Node v20.19.0 (agent processes used a Node 24.13.0 install for the bundled ripgrep)

Logs / additional context

Possibly related, though I don't believe any is a duplicate:

• [Workspace] system-prompt anchor never reaches protocol-v1 harnesses: Claude Code and Codex lose absolute-cwd grounding on all platforms #3126 — [Workspace] system-prompt anchor never reaches protocol-v1 harnesses, "Claude Code and Codex lose absolute-cwd grounding". That is about whether the agent is told its cwd in prompt text; this report is about the spawned process's actual OS working directory. Different layer, but if cwd plumbing is weak right now the two may share a root cause.
• [Bug] Per-channel ACP sessions are never released: on Windows each live session pins a full agent process tree (~33 procs / ~2 GB), exhausting the commit limit until Windows kills the WebView2 host and the desktop silently renders black #2961 — per-channel ACP sessions never released, pinning an agent process tree (Windows, manifests as memory).
• [Bug] Buzz Desktop leaves large numbers of terminal/console processes running (not cleaned up after agent tasks) #2413 (closed) — Buzz Desktop leaving large numbers of processes running (Windows, about reaping finished processes rather than live ones spinning).

Workaround: kill the session trees (parent + MCP children + rg, or they reparent to launchd as orphans) and quit Buzz. Killing alone is not enough — Buzz respawns them while it is open.

[jatinder14]

I am taking this. I found the managed-agent spawn boundary still permits a missing workdir to inherit the desktop process CWD. I will make that state fail safely instead of allowing a session to start at filesystem root, with coverage for the guard.