[BUG] Desktop (Windows): hook-forced permission prompt for git commit answered "Allow once" without the user seeing it

Summary

In the Claude Code desktop app on Windows, a PreToolUse hook returned permissionDecision: "ask" for a git commit. The app emitted a permission request, and 4 seconds later the request was answered "Allow once" from inside the app. I (the user) never saw a prompt and did not knowingly approve it. Remote Control was off and no notification was clicked. The commit ran.

Every other commit in the same session today prompted me normally.

Environment

• Windows 11 Home (10.0.26300).
• Claude Code desktop app, Code tab. The app version is blank in main.log ("appVersion:" with no value). The Claude Code binary is ...\claude-code\2.1.299\...\claude.exe.
• Session permission mode: auto. From main.log: [permissionMode] spawn local_89b5ed02-... mode=auto provisional=false source=unknown autoState=unknown requested=auto effective=auto mdmAutoOff=false.
• The session was started from another session, the app's "start session from a session" feature.
• User-scope PreToolUse hook (matcher Bash|PowerShell). It returns permissionDecision: "ask" for git commit, push and the like.
• No allow rule for git exists in any settings file. User settings.local.json allows only Bash(claude *).

Timeline (local time, 2026-10-15)

From %LOCALAPPDATA%\Claude\Logs\main.log:

18:36:30 [info] LocalSessions.sendMessage: sessionId=local_89b5ed02-55c6-450b-9cf6-ee5c5ac0831d, messageLength=20, ...
          (my message: "commit what we have.")
18:36:48 [info] Emitted tool permission request 55cd3fee-6e34-488b-b995-4f7d2cbca2e6 for Bash in session local_89b5ed02-...
18:36:52 [info] LocalSessions.respondToToolPermission: requestId=55cd3fee-..., decision=once, hasUpdatedInput=true
18:36:52 [info] Received permission response for 55cd3fee-...: once (tool: Bash)
18:37:03 [info] LocalSessions.startSideChat: sessionId=local_89b5ed02-...

From the session transcript (JSONL), on the same tool call:

attachment hook_success PreToolUse:Bash, durationMs 673, stdout:
{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"ask","permissionDecisionReason":"Outward/mutating action (git commit) intercepted by the global git/gh guard - confirm you authorized this (propose-and-wait)."}}

The tool result (the finished commit) follows. Nothing in the transcript records who approved it.

What I ruled out

• The hook: run again on the exact same command text, it answers "ask" in about 0.6 s. The transcript shows it answered "ask" at the time.
• A stored "Always allow" rule: none exists. The decision was "once", and no git rule is in any settings file.
• Remote Control: remote-control.log shows state off all day, with 0 polls and 0 sessions.
• A notification click: the app logs those separately as Permission ALLOW_ONCE from notification { ... backend: 'electron' }. That line appears for five other approvals in this session today, but not for this one.

Other approvals the same day, for comparison

This session emitted 25 permission requests that day. Five were answered from a Windows notification ("from notification"); the rest, including this one, were answered in the app (respondToToolPermission ... decision=once). Every decision was "once". Response delays range from 2 s to about 3 minutes, so a 4-second answer is not unusual in itself. I approved all the others knowingly.

What I suspect (unverified)

An input not meant for the prompt was taken as "Allow once". Two candidates:

• A keystroke: "Allow once" has a keyboard shortcut (see #102136, ⌘↵ on macOS), pressed while I was typing elsewhere in the app. A side chat opened 11 s later, so I was interacting with the app at that moment.
• A click: a click to focus or refocus the window landed on the prompt. This is the same class as #73353, which is reported for the terminal.

Expected behavior

• A hook-forced "ask" prompt in the desktop app should be answered only by a deliberate action on the prompt itself.
• The log should record which input answered a permission request (mouse click on which button, keyboard shortcut, notification, remote). Today respondToToolPermission does not say, so a user cannot tell after the fact how a command got approved.

Related issues

• #79501: auto-mode sessions ran Bash calls matching ask rules and hook "ask" decisions with no prompt shown. Closed as not reproduced; background sessions, macOS.
• #73353: a click that refocuses the window submits the default option of a permission prompt. Terminal, macOS; duplicate of #70685.
• #102136: the desktop permission prompt's default button and shortcuts changed (open, 2026-10-14).

Not included on purpose

Organization and account identifiers that appear in the logs. Request ids and session ids are kept, in case Anthropic can correlate them server-side.