debuglisted

# Debugging a failing Phosphor session Work outside-in. The layer that prints the error is usually not the layer that caused it: a turn that fails inside the Claude CLI surfaces in Phosphor as a generic red message, and the real reason is one or two layers down. The stack, and what each layer keeps: ``` Phosphor renderer → chat bubble; keeps nothing after unmount Phosphor main → ~/Library/Logs/Phosphor/phosphor.log (spawn argv, pi stderr, crashes) pi subprocess → ~/.pi/agent/sessions/<mangled-cwd>/<ts>_<id>.jsonl provider → ~/.claude/projects/<mangled-cwd>/<session-id>.jsonl (Claude CLI only) ``` ## 1. The debug log ```bash tail -100 ~/Library/Logs/Phosphor/phosphor.log ``` Always on, no flag to set — a log you must enable first is never on when the bug happens. Rotates at 5MB keeping one `.1`. macOS path shown; Linux is `~/.config/Phosphor/logs/`. From a shipped build the path is also available over IPC (`app:debugLogPath`, `app:revealDebugLog`). What it answers: - `[pi] spawn` — the exact argv and cwd. Check `--provider`, `--model`, `--thinking` here before believing what the UI claims. - `[pi] stderr` — the provider prints failure reasons here. - `[pi] exited unexpectedly` — the code/signal behind a "pi crashed" banner. - `[app] session start` — versions and **PATH**. A GUI app inherits launchd's PATH, not your login shell's, so `pi` or `claude` can resolve to a different binary (or none) than the same command in a terminal. ## 2. The