[BUG] Windows: Drive Letter Change Triggers Permission Resolver Explosion + Arbitrary .claude/ Directory Creation Outside Workspace

Description

When a Windows user's SSD changes drive letters (e.g., C: to F: after RMA, USB adapter, or docking station scenario), Claude Code's Permission Resolver fails catastrophically:

1. Command-specific wildcard permissions (e.g., Bash(powershell:*), Bash(git -C:*)) stop being matched
2. settings.local.json bloats from ~1KB to 25KB+ with redundant entries (5 backup files preserved as evidence)
3. Agent creates .claude/ directories in arbitrary locations outside the project workspace
4. Built-in tools (Read, Write, Glob, Edit) appear to operate outside bwrap sandbox — observed behavior: .claudeignore only affects grep results, not filesystem operations via built-in tools (ref: #15789)

Note: Security-relevant aspects (Sandbox Escape, Arbitrary File Write) have been reported separately via Anthropic's Vulnerability Reporting Form per SECURITY.md policy. This issue focuses on the reproducible bug behavior.

Related Issues / Advisories

• GHSA-ff64-7w26-62rf — Sandbox Escape via Persistent Configuration Injection
• #27757 — 607K token system prompt with large permissions.deny list (same root cause: permission accumulation)
• #15789 — Sandbox mode bypass via built-in tools
• #22197 — Sandbox violation for internal files

Steps to Reproduce

1. Set up Claude Code project on Windows drive C: with workspace C:\Users\...\ProjectFolder
2. Configure permissions with command-specific wildcards (e.g., Bash(powershell:*), Bash(git -C:*), Bash(luacheck:*)) in settings.local.json
3. Move SSD to different machine/port (drive letter changes from C: to F: — common in RMA, USB adapter, docking station scenarios)
4. Open same project in Claude Code — observe permission explosion and .claude/ directories appearing outside workspace

Expected Behavior

Permission Resolver should use relative paths from workspace root and handle drive letter changes gracefully. Wildcard matching should work regardless of drive prefix.

Actual Behavior

1. Wildcard permissions not recognized after drive change — Permission Resolver generates redundant literal entries instead of matching existing wildcard patterns
2. settings.local.json bloats progressively — from 1.1 KB (clean) to 25.2 KB (peak corruption in sandbox-escaped copy) / 6.2 KB (main project, partially self-repaired). Parser collapses under accumulated entries
3. Arbitrary .claude/ directory creation — Agent writes .claude/ directories into locations outside project root:

• node_modules/es-abstract/.claude/ (177 bytes)
• Another user's Windows profile directory on the same SSD
• External file sorting directories

1. Built-in tools appear to bypass sandbox — observed: .claudeignore only affects grep, not Read/Write/Glob/Edit filesystem operations (ref: #15789)

Evidence

• 5 corrupted settings.local.json files preserved in backup (clean 1.1 KB vs corrupted 25.2 KB — same project, different drive letters)
• .claude/settings.local.json found inside node_modules/es-abstract/ (177 bytes — proof of out-of-workspace file creation)
• Full forensic HDD scan (71,068 files indexed) confirming contamination scope
• Anthropic Support Tickets: #215473453236303 and 4 follow-ups
• Public artifact with architecture-level analysis: https://claude.ai/public/artifacts/cb29b988-330c-4ea2-a216-edaa9cecdab9

Root Cause Analysis

The Permission Resolver uses absolute Windows paths internally. When the drive letter changes (C: to F:), previously stored path references become invalid. Instead of failing gracefully, the resolver:

1. Cannot match existing wildcard permissions against the new path prefix
2. Creates new redundant entries for every tool invocation
3. Does not validate that .claude/ directory creation stays within workspace boundaries
4. Built-in tools (Read/Write/Glob/Edit) operate outside the bwrap sandbox entirely

Real-World Impact

This bug affected an active production environment used for legal proceedings under court deadlines, medical document management, and file archiving. The sandbox escape resulted in:

• .claude/ directories and corrupted settings.local.json files written to 5 unauthorized locations
• 175 DICOM medical imaging files nearly lost during contamination cleanup
• settings.local.json bloated from 1.1 KB to 25.2 KB, causing complete agent failure
• 48-hour emergency system rebuild required to restore functionality

Suggested Fix

1. Permission Resolver should canonicalize paths relative to workspace root, not absolute drive paths
2. Wildcard matching must work regardless of drive prefix
3. .claude/ directory creation must be restricted to workspace root — enforce with path validation before mkdir
4. Built-in tools should respect sandbox boundaries, not just bwrap-wrapped Bash commands
5. Add drive letter change detection/migration logic for Windows

Environment

• Claude Code v2.1.66-76 (VS Code Extension)
• Windows 11 Pro 10.0.26200
• MSI Katana 17 B12VFK, i7-12650H, RTX 4060 8GB
• Reproduced with SSD via USB adapter (drive C: → F:)