Windows: TUI input dead while a PreToolUse hook child blocks on uninterruptible I/O (network/cloud drive)

Windows: TUI input dead while a PreToolUse hook child blocks on uninterruptible I/O

Summary

On Windows, when a registered hook subprocess blocks on uninterruptible I/O (a wedged
network / cloud-sync drive — pCloud/P: in our case), the Claude Code TUI stops responding to
input: Esc does nothing, typing is dead, and the session cannot be steered or cancelled. The
only recovery is killing the process, which loses in-flight work. A TUI-side watchdog that
abandons a hung hook child and surfaces it (rather than blocking the input loop on it) would keep
the session alive through the wedge.

Environment

• OS: Windows 11
• Shell: PowerShell (primary) + Git-Bash tool
• Hook load: ~40 hooks bound to PreToolUse:Bash (large but legitimate config)
• Trigger surface: a P: drive backed by a cloud-sync client (pCloud). When the client wedges,

even Path.exists() on P: enters an uninterruptible wait in the hook child.

Repro (observed, not synthetic)

1. Register a PreToolUse:Bash hook whose code path touches a network/cloud drive.
2. Wedge that drive (disconnect the sync client mid-session).
3. Issue any Bash tool call. The hook child spawns and blocks in uninterruptible I/O.
4. The TUI input loop is now unresponsive — Esc, Ctrl+C-equivalent, and typing are all dead;

the remote-control/IDE channel disconnects. The session is unrecoverable without a kill.

Impact

• Session-loss class. An entire multi-step workflow (a multi-PR workflow in our case)

was lost because the session could not be cancelled or redirected while the child hung.

• Amplified by hook count: with N hooks on PreToolUse:Bash, any one hook that can block on I/O

becomes a single point of session freeze.

Suggested fix (TUI side)

A hook-execution watchdog in the TUI: give each hook child a wall-clock budget; if it exceeds the
budget, abandon the child (detach + reap in the background), surface a non-blocking notice
("hook X exceeded Ns, abandoned"), and return control to the input loop. Abandon-and-surface beats
block-and-freeze: a slow hook should degrade the guarantee that hook provides, not the whole
session's steerability.

What we did on our side (defense-in-depth, not a substitute for the TUI fix)

• A P:-wedge circuit breaker (a bounded kill-and-abandon canary + a shared wedge marker) so our own

scripts skip the drive when it is unsafe rather than hanging.

• Hook-path validation to surface broken/unexpanded hook configs at session init before they can

brick a session mid-run.

These keep our hooks from hanging, but any third-party or future hook that blocks on I/O
reintroduces the freeze — hence the request for a TUI-side watchdog as the root-cause fix.

Ask

Would the team consider a per-hook wall-clock watchdog in the Windows TUI input loop (abandon +
surface after N seconds) so an uninterruptible hook child cannot freeze session steerability?