Allow-listed Read/Write silently soft-deny after ~600s permission timeout in remote/multi-session VS Code

Summary

When running the VS Code extension over code serve-web (remote) with multiple concurrent sessions sharing one extension host, a Read/Write tool call that needs a permission decision can hang for the full default permission timeout (~600000 ms) and then resolve to a phantom rejection — even though the user never saw or rejected a prompt.

The tool result the model receives is:

The user doesn't want to take this action right now. STOP what you are doing and wait for the user to tell you how to proceed.

…with toolUseResult: "Error: undefined".

Why this is a bug

1. The message is the engine's interrupt/abort string (defined inline next to [Request interrupted by user]), not the real user-reject string ("...doesn't want to proceed with this tool use. ...rejected (eg. if it was a file edit...)"). So an unanswered/aborted permission request is being surfaced to the model as if the user actively rejected it.
2. The affected tools (Read, Write) were already present in permissions.allow in .claude/settings.json, yet still round-tripped to the IDE permission channel.
3. There is no responder, so the request hits the default ~600 s timeout and silently soft-denies. The user perceives nothing; the model perceives a rejection it must obey.

Evidence (observed)

• Two occurrences in one session; each preceded by the tool call hanging exactly 600.016 s and 600.020 s (= default 600000 ms timeout, to the millisecond) before the deny result arrived.
• Recorded result: toolUseResult: "Error: undefined" (empty permission response coerced to the soft-deny).
• Only Read/Write (which round-trip to --permission-prompt-tool stdio) were affected; never Edit (auto-accepted under --permission-mode acceptEdits, no round-trip).
• No PreToolUse hook matched Read, ruling out user hooks.

Environment

• Extension anthropic.claude-code 2.1.167, native binary, launched by the VS Code extension host over code serve-web (remote), flags --permission-prompt-tool stdio --permission-mode acceptEdits.
• Three concurrent native engines sharing one extension host process. Only the focused webview can render a prompt, so a background session's permission request is never surfaced.

Repro

1. code serve-web (remote), open 3 concurrent Claude Code sessions in one window, --permission-mode acceptEdits.
2. In a non-focused session, trigger a Read.
3. Expected: prompt is shown, or the permissions.allow rule is honored (no prompt).
4. Actual: ~600 s hang, then a phantom "The user doesn't want to take this action right now" rejection.

Suggested fixes

• Honor permissions.allow for Read/Write so they don't require an IDE round-trip.
• A permission request with no responder should surface as a visible, fast, retryable error — not a silent 10-minute hang that coerces to a soft-deny.
• Distinguish "aborted/timed-out permission request" from "user rejected" in the message sent to the model.