VS Code extension v2.1.116: bypassPermissions silently stops working in second+ chat per restart, despite correct launch flags

Summary

In the Claude Code VS Code extension v2.1.116, bypassPermissions mode works for the first chat after a VS Code restart, then silently stops working for every subsequent chat — despite the claude binary being launched with identical and correct flags (--permission-mode bypassPermissions --allow-dangerously-skip-permissions). Every Write, Edit, and Bash call in subsequent chats produces a permission dialog. Only a full VS Code restart restores functionality, and only for the next single chat.

This is reproducible, is NOT a local configuration issue (proven below by identical process flags), and renders the extension effectively unusable for any workflow that requires multiple concurrent or sequential chats.

Environment

• Extension: anthropic.claude-code-2.1.116-darwin-arm64
• VS Code: 1.x (macOS Sonoma 15 / Darwin 24)
• macOS 15 (Darwin 24.x, Apple Silicon)
• Paid user: Claude Max \$200/month
• Settings (both files verified via git commit a7978dd in user's dotfiles):
• ~/dotfiles/vscode/settings.json: \"claudeCode.initialPermissionMode\": \"bypassPermissions\" + \"claudeCode.allowDangerouslySkipPermissions\": true
• ~/.claude/settings.json: \"defaultMode\": \"bypassPermissions\" + comprehensive additionalDirectories list including /Users/slate/.claude

The Definitive Evidence: Identical Launch Flags, Different Behavior

Two Claude chats were running simultaneously under the same VS Code instance, one silent and one prompting. Both were launched with identical flags per ps auxww:

claude --output-format stream-json --verbose --input-format stream-json 
       --max-thinking-tokens 31999 
       --permission-prompt-tool stdio 
       --resume <session-id> 
       --setting-sources=user,project,local 
       --permission-mode bypassPermissions 
       --allow-dangerously-skip-permissions 
       --include-partial-messages --debug --debug-to-stderr 
       --enable-auth-status --no-chrome --replay-user-messages

Session A (id ending 6c7be06d): Silent on all file Write/Edit to ~/.claude/* paths. Working as expected.

Session B (id ending a5cbcb58): Prompted for every single file Write (to ~/.claude/skills/*/SKILL.md, ~/.claude/scripts/memory-bloat-gate.py, ~/.claude/output-styles/explanatory-plain.md), every Edit (to ~/.claude/projects/-Users-slate/memory/MEMORY.md and settings.json), AND every Bash call (including benign mkdir -p /Users/slate/.claude/output-styles). Approximately 30+ dialogs across a single GSD session.

Both sessions were started in new chats (not resumed) after a confirmed VS Code restart. Both target paths are inside additionalDirectories.

Because the CLI flags are identical, this is NOT a configuration propagation problem. The regression is inside the extension's runtime permission-handling code — specifically, some per-chat or per-webview state that gets polluted after the first chat and is not cleared until VS Code is fully killed and restarted.

Reproduction

1. Ensure claudeCode.initialPermissionMode: bypassPermissions and claudeCode.allowDangerouslySkipPermissions: true in VS Code user settings.
2. Full Cmd-Q quit of VS Code.
3. Reopen VS Code. Start a new Claude chat. Run any Write/Edit/Bash — auto-approved as expected.
4. Without quitting VS Code, start a second new Claude chat. Run the same kinds of tool calls.
5. Observe that every tool call now produces a permission dialog despite the mode indicator still showing \"Bypass Permissions.\"

Expected Behavior

Once bypassPermissions is the initial mode and allowDangerouslySkipPermissions is true, every new chat launched under the same VS Code process should auto-approve file operations and Bash equally, matching the CLI behavior (which does work correctly — confirmed on the same machine).

Actual Behavior

Only the first chat per VS Code process respects bypass mode. Every subsequent chat prompts on nearly every tool call. The --permission-prompt-tool stdio flag is passed to every chat, and it appears the extension's stdio handler is what's drifting — it begins routing permission requests back to the webview UI despite bypass mode being active.

Related Prior Issues (not duplicates — this filing adds evidence none of them had)

• #35822 (\"permission mode resets from bypassPermissions to auto/acceptEdits mid-conversation\") — closed NOT_PLANNED after the reporter self-closed, but comments from multiple other users confirm the bug persists. Did not include process-level launch-flag evidence.
• #36348 (\"VSCode extension ignores bypassPermissions defaultMode setting\") — closed COMPLETED in an earlier fix, but the underlying class of bug clearly still exists in 2.1.116.
• #41325, #47192, #38511 — all closed as DUPLICATE, pointing to the ongoing pattern.
• #43953 — decompiled extension.js showed requestToolPermission always forwards to webview for non-Chrome tools. The flag-passing evidence in this filing suggests the stdio layer has a similar unconditional-forward path under certain per-chat states.

Why I'm Asking for a Follow-Up and Refund

As a paid Max-tier subscriber, the extension is my primary access to Claude Code. The \"one chat per VS Code restart\" workaround is not workable for my real workflow (multiple parallel GSD projects). This has cost me approximately 75%+ of my weekly rate-limit allocation this week on diagnostic cycles alone, because the model I was using to investigate could not consistently execute the tool calls it needed due to these prompts.

Please:

1. Re-open and assign an engineer — the process-flag evidence above should narrow the bug to the extension-side stdio handler or per-webview state management.
2. Provide a status update on whether this is being investigated and an expected fix window.
3. Refund / credit the week's Max allocation. I'll submit the refund request separately to support@anthropic.com referencing this issue.

Additional Diagnostic Data Available on Request

• Full ps auxww output from both sessions
• VS Code user settings JSON
• ~/.claude/settings.json
• Screenshots of each permission dialog (Write, Edit, Bash)
• Git commit reference for the fix attempts made on the user's side (proving settings were applied correctly)
• Session IDs for both affected chats

Happy to provide any or all of the above directly.