[BUG] No hook event fires for sandbox network permission popup in v2.1.120 (regression from v2.1.76)

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (v2.1.120)

What's Wrong?

When Claude Code's sandboxed Bash tool needs to reach a host not in the allowlist, the in-chat "Allow network connection to this host?" popup appears. While that popup is visible (and after the user clicks Yes), no hook event fires at all for the permission decision.

This breaks external notifiers (e.g. singularityinc.claude-notifier) that rely on hooks to surface popups to the user via OS notifications. Result: the user has no idea a popup is waiting and approval is silently delayed by tens of seconds to minutes.

Same bug as the closed-by-stale-bot #23217 — never actually fixed — and now strictly worse: per GMNGeoffrey's last comment on #23217, in v2.1.76 the Notification event at least fired as a workaround. In v2.1.120 even that's gone.

What Should Happen?

PermissionRequest should fire when the popup appears, with permission_type: "sandbox_network" and the target host in permission_details. The docs at https://code.claude.com/docs/en/hooks describe exactly this ("When a permission dialog appears"), but it doesn't fire in practice.

Steps to Reproduce

1. On Claude Code v2.1.120, register a hook on every documented event in ~/.claude/settings.json that logs its tag + input JSON to a file. Authoritative event list (29 entries, from the settings.json schema): PreToolUse, PostToolUse, PostToolUseFailure, PostToolBatch, Notification, UserPromptSubmit, UserPromptExpansion, SessionStart, SessionEnd, Stop, StopFailure, SubagentStart, SubagentStop, PreCompact, PostCompact, PermissionRequest, PermissionDenied, Setup, TeammateIdle, TaskCreated, TaskCompleted, Elicitation, ElicitationResult, ConfigChange, WorktreeCreate, WorktreeRemove, InstructionsLoaded, CwdChanged, FileChanged.
2. From sandboxed Bash, run curl https://<some-host-not-in-allowlist> (e.g. curl https://archive.org).
3. The in-chat popup "Allow network connection to this host?" appears. Approve it.
4. Inspect the log.

Observed: Only PreToolUse, PostToolUse, PostToolBatch fire (standard tool lifecycle — no host info, fires before the sandbox check). Nothing about the permission decision reaches any hook.

Expected: PermissionRequest fires with permission_type: "sandbox_network", allowing a hook to either auto-decide or surface the popup to the user (e.g. via an OS notification).

Empirical Evidence

Tested on v2.1.120 (VSCode native extension, macOS). Triggered popups with multiple non-allowlisted hosts including cloudflare.com, icanhazip.com, duckduckgo.com, archive.org. User actively watched and approved each popup as it appeared.

Cleanest test (archive.org, user approved within ~2.7s of the popup appearing):

| Event | Times fired |
|---|---|
| PostToolBatch | 1 |
| PostToolUse | 1 |
| PreToolUse | 1 |
| All 26 other events including PermissionRequest, PermissionDenied, Notification, Elicitation, ElicitationResult | 0 |

Earlier tests with slower approvals (14–26s waits) showed the same firing pattern, confirming the result is independent of timing.

Claude Code Version

2.1.120

Platform

VSCode native extension

Operating System

macOS

Additional Information

The bug exists for both sandbox-blocked hosts that prompt AND hosts that get silently denied with a timeout — neither path fires any hook. The popup itself is rendered by the bash-tool sandbox layer entirely outside Claude Code's hook system.

References:

• #23217 (closed by stale-bot, never fixed)
• #41726 (duplicate of #23217)