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

**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 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:
```sh
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:

- #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.
- #2961 — per-channel ACP sessions never released, pinning an agent process tree (Windows, manifests as memory).
- #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.