Desktop auto mode: pending Bash permission request resolved itself after 37 hours and ran unattended

Summary

In the desktop app (Code tab, auto mode), a Bash tool permission request sat pending for about 37 hours, then was withdrawn and the command ran at 3:23 AM with no user response. Nobody approved it: the user was asleep, and Remote Control logged no activity at that hour.

Environment

• Claude desktop app 2.26454.2 (Windows 11 Enterprise 26100), Code tab, local session
• Claude Code 2.1.292
• Permission mode: auto, autoMode.classifyAllShell: true
• Remote Control on for the session

Timeline (local time, from %LOCALAPPDATA%\Claude\logs\main.log)

| Time | Log line |
|---|---|
| Oct 6 14:04:17 | Emitted tool permission request 62b8b0f0-... for Bash |
| Oct 6 14:14:27 | respondToToolPermission: requestId=62b8b0f0-..., decision=once (the user approved this one normally) |
| Oct 6 14:19:45 | Emitted tool permission request eebcdbfc-47fb-4a44-a206-e30fdef88024 for Bash |
| Oct 6 15:14 | Lid closed, Modern Standby (Windows System log, Kernel-Power 506) |
| Oct 6 17:25:44 | [keep-awake] session ... no longer counted (stalled) |
| Oct 7 00:09 | Machine resumed and stayed awake; the request is still pending |
| Oct 8 03:22:00 | [oauth-v2] ... using cached token (inference token lookup) |
| Oct 8 03:23:09 | Permission request eebcdbfc-47fb-4a44-a206-e30fdef88024 for Bash aborted |
| Oct 8 03:23:20 | Tool result recorded in the transcript; the command's git commit is stamped 03:23 |
| Oct 8 03:23:34 | [CCD CycleHealth] healthy cycle ... (135426s, hadFirstResponse=true) |

There is no respondToToolPermission line for eebcdbfc. The command (a commit, a push to a feature branch, and rm -rf of two temp folders it created) only executed at 03:23. That rules out a slow command: it waited the whole time and never started.

Expected

A permission request with no answer either stays pending until a person answers, or fails or times out visibly. It should not resolve to "run" more than a day later with nobody present.

Actual

The prompt was withdrawn ("aborted") and the tool ran unattended about 37 hours later. Our guess, not verified: the auto mode classifier call for this command stalled, the UI prompt stayed up meanwhile, and when the classifier finally returned "allow" the pending prompt was cancelled. If so, two problems: (1) a classifier call can hang for more than a day with no timeout, and (2) a late verdict can run a command the user was being asked about, long after the context changed.

Impact

Low this time (feature-branch push and temp cleanup), but the same path could run a riskier command unattended.