postToolUse hook deadlocks after write-permission request, process spins at 99% CPU and ignores SIGTERM

[CianH]

Describe the bug

A resumed Copilot CLI session entered a permanent deadlock after dispatching the postToolUse hook for an edit tool call that triggered a PermissionService write request. The process burned a full CPU core at 99% for 10 days before I noticed. It accepted no further input, produced no further log output, and ignored SIGTERM. Only kill -9 terminated it.

Affected version

1.0.35.2 (per the debug log header: github_copilotcli_cliversion=1.0.35.2)

Steps to reproduce the behavior

I cannot construct a deterministic reproduction. The deadlock happened spontaneously inside a long-running --resume session. The freeze coincides exactly with the dispatch of a postToolUse hook following a PermissionService write request:

1. Run copilot --resume=<session-id> against any session
2. Use the session normally for ~2 hours
3. At some point the agent issues an edit tool call against a local file
4. The tool call routes through PermissionService (kind=write)
5. postToolUse hook dispatch begins — no further log lines are ever written
6. The process continues running at 99% CPU and ignores SIGTERM

Expected behavior

• The postToolUse hook should complete (or fail with a logged error) and return control to the event loop.
• The process should remain responsive to SIGTERM.

Additional context

Sanitised log around the freeze point (last 14 lines before logging stops; process kept running for 10 days after this):

01:16:02.773Z [DEBUG] Forwarding event for session <id>: assistant.message
01:16:02.773Z [DEBUG] Forwarding event for session <id>: tool.execution_start
01:16:02.773Z [DEBUG] Forwarding event for session <id>: hook.start
01:16:02.773Z [DEBUG] Dispatching preToolUse hook for session <id>
01:16:02.791Z [DEBUG] Forwarding event for session <id>: hook.end
01:16:02.791Z [DEBUG] Tool calls count: 1
01:16:02.791Z [DEBUG] Running tool calls in parallel
01:16:02.791Z [DEBUG] Adding operation to queue. Current queue length: 0
01:16:02.791Z [DEBUG] Processing operation. Remaining queue length: 0
01:16:02.791Z [DEBUG] edit: <local-file>
01:16:02.792Z [DEBUG] Permission request (kind=write): routing via PermissionService
01:16:02.793Z [DEBUG] Operation completed. Remaining queue length: 0
01:16:02.793Z [DEBUG] Forwarding event for session <id>: hook.start
01:16:02.794Z [DEBUG] Dispatching postToolUse hook for session <id>
[no further log output for 10 days while process spins at 99% CPU]

The edit tool call's Operation completed reaches the queue cleanup BEFORE the postToolUse hook is dispatched — but the postToolUse line is the last log entry. Looks like the hook dispatch entered a state from which control never returned.

Coincident factor (may or may not be related): safari-mcp MCP child process had been logging WebKit memory warnings in the hour leading up to the freeze:

00:19:35Z [ERROR] [mcp server safari-mcp stderr] WebKit memory warning: 2126MB (threshold 2100MB, limit 3000MB) — 0 MCP tabs open
00:39:35Z ... 2689MB ...
00:45:05Z ... 2195MB ...
01:03:26Z ... 2242MB ...
01:08:26Z ... 2750MB ... (8 minutes before main process freeze)

The 2750MB warning at 01:08:26 was 8 minutes before the freeze. Could be a stuck IPC between the main copilot process and an OOM-distressed safari-mcp child — but this is speculation; the freeze pattern in the log is consistent with a pure permission-prompt deadlock too.

SIGTERM behaviour: kill <pid> had no effect on the deadlocked process. Only kill -9 terminated it. The main event loop should remain responsive to SIGTERM even during hook dispatch.

Environment:

• macOS, Apple Silicon
• Node v24.11.1
• Copilot plan: enterprise
• Process accumulated ~49 hours of single-core CPU time over 10 calendar days before being killed

[BGMLAI]

Hooks need deadlines and cancellation boundaries. A postToolUse hook should run in a supervised task with a hard timeout, bounded CPU, and a finally path that releases every permission lock. SIGTERM handling must remain outside that hook task so shutdown cannot be starved by a spin. A targeted stress test can pause the permission response while the hook starts, then cancel, resume, and terminate; all paths should produce one terminal event and no busy loop.