Bypass mode wedges chat input when Write creates new file under <workspace>/.claude/

Summary

When the Write tool is used to create a new file at any path under the workspace's local .claude/ directory (e.g. <workspace>/.claude/skills/<skill>/system/<new-file>.md), the extension fires an approval prompt despite permissionMode: bypassPermissions. The prompt's UI then crashes:

1. The diff renderer fails with Unable to read file '_claude_vscode_fs_left:/...' (custom URI scheme cannot resolve a not-yet-existing file)
2. The Claude Code chat input becomes wedged (dimmed placeholder, accepts no keystrokes; integrated VSCode terminal remains responsive)
3. The corrupted session state is persisted to ~/.claude/projects/<workspace>/<session-id>.jsonl

Reload Window, toggling permission mode, and a full Cmd+Q quit do not recover the session, because the extension respawns the CLI with --resume <same-id>, which faithfully reloads the broken state from disk.

Reproducer

1. Start a Claude Code session with "claudeCode.initialPermissionMode": "bypassPermissions" and "claudeCode.allowDangerouslySkipPermissions": true in user settings.json
2. Have Claude Write a new file at a path under <workspace>/.claude/ that does not yet exist (e.g., <workspace>/.claude/skills/test-skill/system/test-file.md)
3. Observe: approval prompt fires (despite bypass), diff renderer pops a "Unable to open" error dialog citing a _claude_vscode_fs_left: URI, chat input becomes unresponsive

Edit to existing files under the same path works fine. Write to existing files works fine. Write to new files outside <workspace>/.claude/ works fine. Only Write of new files inside <workspace>/.claude/ triggers it.

Expected vs Actual

• Expected: With bypass enabled, the Write proceeds without prompting. (Or, if writes inside <workspace>/.claude/ are intentionally gated for safety, the prompt should render correctly inline and the chat should remain responsive.)
• Actual: Approval prompt fires, diff renderer crashes on a virtual URI it cannot resolve, chat input wedges, session state is permanently corrupted on disk.

Forensic findings

In a corrupted session's .jsonl, two independent break events occurred several minutes apart, both via Write to the same new file path under <workspace>/.claude/skills/<skill>/system/. Pre-break, the same session executed many Write/Edit calls to other locations cleanly. Post-break, the user's tool result records "reason: bypass not working" with is_error: true.

Workaround (until upstream fix)

When creating a new file under <workspace>/.claude/:

• Use Bash touch <path> first, then Edit to populate (Edit on existing files works under bypass)
• Or use Bash cat > <path> <<'EOF' ... EOF directly

Recovery from a corrupted session

The standard reset (toggle / Reload Window / Cmd+Q) does not work — --resume reloads the broken state. The minimum sufficient fix is:

1. Kill the broken CLI process (or close the VSCode window)
2. Rename the saved session aside:

• mv ~/.claude/projects/<workspace>/<session-id>.jsonl{,.broken}
• mv ~/.claude/projects/<workspace>/<session-id>{,.broken}

1. Start a fresh Claude Code session — bypass, chat input, and inline rendering all restore

Environment

• Claude Code extension: 2.1.120 (darwin-arm64)
• VSCode: latest stable
• macOS: Darwin 25.3.0
• Settings: claudeCode.initialPermissionMode: bypassPermissions, claudeCode.allowDangerouslySkipPermissions: true, claudeCode.preferredLocation: panel

Observed 3 nights running 2026-04-23 through 2026-04-26.