Desktop app (Code tab): built-in edit-preview PostToolUse hook times out at 60 s on ~60 % of Edit/Write calls

Versions: Claude desktop app, Claude Code 2.1.286 and 2.1.288 (entrypoint: claude-desktop), macOS (Darwin 25.6).
Permission mode: bypass. Also seen in 2.1.281, where it was worse (982 timeouts in 2,011 edits).

What happens
After an Edit/Write/MultiEdit, the tool result arrives exactly 60 s after the tool call, and the transcript gets
{"type":"hook_cancelled","hookName":"PostToolUse:Edit","hookEvent":"PostToolUse"}. When the hook does finish, it
injects the app's preview hint ("No preview server is running. Before ending your turn, … call preview_start and follow
<verification_workflow>"), so the hook that hangs is the desktop app's built-in edit-preview hook, not a user hook.

Numbers (Oct 4–13, one project, 4 sessions)

| | edits | cancelled at 60 s |
|---|---|---|
| all (main thread + subagents) | 1,439 | 881 (61 %) ≈ 14.7 h of waiting |
| session on 2.1.286, main thread | 178 | 134 (75 %) |
| session on 2.1.288, main thread | 346 | 202 (58 %) |
| .prisma / .sql / .json files | 22 | 22 (100 %) |

Why it's not the user's hook

• The project's only PostToolUse hook (format + lint of the edited file) runs in 0.06 s on .prisma (it exits right

away for that extension) and in ~0.9 s on .ts/.tsx, measured outside the session. .prisma edits still time out
100 % of the time.

• The hook that gets cancelled has the same toolUseID as the app's preview-hint hook_additional_context.
• A plugin hook can't shorten the wait: a test hook with a 20 s sleep showed that these desktop hooks run inside the

tool execution, and the plugin's PostToolUse handler never fired.

Expected: the preview hook returns right away when no preview server is running (or at least uses a short timeout),
and there is a setting to turn it off for projects that don't use the Browser pane.

Impact: with subagents that make hundreds of edits, a feature session waits hours on this hook.