[BUG] PermissionRequest hook stops firing after CLI restart on Windows (v2.1.233)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

PermissionRequest hook not firing after CLI restart (v2.1.233, Windows, Manual mode)

Environment

• Claude Code version: 2.1.233
• OS: Windows (PowerShell + Git Bash)
• Login: Claude Pro account
• Default permission mode: Manual
• Project: uses .claude/hooks/permission_request.py registered under PermissionRequest in .claude/settings.json

Summary

Mid-session, the PermissionRequest hook stopped firing entirely. No permission dialogs appeared for Bash commands that should require confirmation (per static allow/ask/deny rules), and the hook's own log file received zero new entries for the remainder of the session — including after a full CLI restart.

Timeline

1. Earlier the same day, in a separate session, the hook worked correctly: static-allow hits, fallthroughs, and ask-gated commands were all logged as expected (log entries present with timestamps, tool name, decision).
2. In a later session (same project, same day), file writes to non-scratchpad paths (tools/*.js, services/api/src/routers/*.py) occurred with no visible confirmation prompt.
3. User confirmed: no confirmation prompt was ever shown for these writes.
4. Diagnostic steps taken (all read-only unless noted):

• Verified hook registration in .claude/settings.json — correct, "PermissionRequest" matcher "Bash|PowerShell|Write", command path correct.
• Manually invoked .claude/hooks/permission_request.py directly — exits 0, appends a correctly formatted line to the log. Hook script itself is functional.
• Ran a write probe: echo test > scratchpad/probe.txt — file was created, but the permission log did not gain a new line (no fallthrough entry), and no prompt was observed.
• Confirmed via byte-for-byte log comparison (line count + md5) that the log truly did not change (control test: appending one line to a copy of the log does change its md5, ruling out a broken comparison).

1. User restarted the CLI entirely (claude relaunched, fresh session, same project directory).
2. On restart, before doing anything else, a system prompt appeared: "Set up auto mode for your environment?" (Set it up / Not now / Don't show again). User selected "Not now".
3. Settings screen shows Default permission mode: Manual (unchanged from before) and Use auto mode during plan: true (default-on, not something the user enabled).
4. Post-restart, re-ran the same write probe (echo test2 > scratchpad/probe2.txt, then echo test3 > scratchpad/probe3.txt) — again created with no visible prompt, and the permission log did not change.
5. Also tried git status (a command that did reach the hook and get logged in the earlier working session that day) — again, no log entry, byte-identical log before/after (md5 confirmed).

Expected behavior

PermissionRequest hook should fire for every Bash/Write tool call that isn't resolved by a static allow rule, exactly as it did earlier the same day in a different session of the same project with identical .claude/settings.json and hook script.

Actual behavior

Hook does not fire at all in the affected session (zero new log lines for any Bash command, including ones with no static-allow match), and no interactive confirmation dialog is shown to the user either. Neither the hook path nor the fallback interactive-prompt path is being triggered. This persists across a full CLI restart.

Suspected cause (unconfirmed)

The appearance of the "Set up auto mode for your environment?" prompt on restart, combined with Use auto mode during plan: true being enabled by default, suggests the newly-rolled-out Auto Mode feature may have silently intercepted permission handling for this session even while Default permission mode was set to Manual. We were unable to directly inspect the active permission mode from within the CLI session (no /status-equivalent output was available to the agent).

Impact

This is a safety-relevant regression: our project relies on .claude/settings.json static deny rules plus a custom hook to prevent commands from reaching a production database file (PharmacyOS-Data, pharmacy_os_prod.db) and to gate destructive commands (git commit/push, rm, alembic upgrade/downgrade) behind confirmation. With the hook silently not firing and no fallback prompt appearing, none of these protections were active for the duration of the affected session.

Request

• Please clarify whether Auto Mode (or "auto mode during plan") can suppress PermissionRequest hook execution and the fallback interactive prompt simultaneously, even when Default permission mode is explicitly set to Manual.
• If this is a known bug, a pointer to the tracking issue would help.
• A way to fully verify/display the active permission mode from within a session (visible to both user and agent) would help catch this class of issue earlier.

What Should Happen?

The PermissionRequest hook should fire for every Bash/Write tool call not resolved by a static allow rule, exactly as it did earlier the same day in a different session of the same project with identical settings.json and hook script.

Error Messages/Logs

Steps to Reproduce

1. Start a Claude Code session with a custom PermissionRequest hook registered in .claude/settings.json, and confirm it fires normally (log entries appear for fallthrough/allow/deny decisions).
2. Continue working in the same or a later session; at some point the hook silently stops firing (no new log entries, no confirmation prompts, no error shown).
3. Restart the CLI entirely.
4. On restart, a "Set up auto mode for your environment?" prompt appears; select "Not now".
5. Try a write probe (e.g. echo test > scratchpad/probe.txt) or any read-only command like git status.
6. Observe: no confirmation prompt appears, and the hook's log file gains no new entries, even for commands that previously reached the hook in an earlier session the same day.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.233

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_