[BUG] VS Code extension: settings writes fail with EPERM because the Windows profile path is character-reversed for RTL (Hebrew) usernames

Summary

On Windows with a Hebrew (RTL) username, the VS Code extension writes settings to a character-reversed profile path. My profile folder is C:\Users\דור, but the extension tries to create C:\Users\רוד — the same three letters in reverse order.

Because a standard user cannot create a new folder directly under C:\Users, the failure surfaces as EPERM rather than ENOENT, which makes it look like a permissions problem.

Error

Every settings write from the webview fails:

Failed to set model: EPERM: operation not permitted, mkdir 'C:\Users\רוד'

From Claude VSCode.log (the reversed path is in the log file itself, not a bidi rendering artifact):

13:56:04.929 [info]  Received message from webview: {"type":"request","requestId":"c30tl0emblo","request":{"type":"apply_settings","payload":"<redacted>"}}
13:56:04.931 [error] Error processing client request: Error: EPERM: operation not permitted, mkdir 'C:\Users\רוד'
13:56:04.933 [info]  Received message from webview: {"type":"interrupt_claude","channelId":"c30tl0emblo"}
13:56:04.934 [warning] Channel not found: c30tl0emblo

Impact

This is not limited to the model picker. It breaks every apply_settings request from the webview — model, effort level, and persisted permission mode. The model pill silently reverts and the panel shows the error toast. There is no way to change the model from the VS Code UI.

Evidence that the path itself is wrong

mkdir of the real profile path can never produce EPERM; only the reversed one does:

fs.mkdirSync('C:\\Users\\דור')                    // EEXIST
fs.mkdirSync('C:\\Users\\דור', {recursive:true})  // OK
fs.mkdirSync('C:\\Users\\רוד')                    // EPERM: operation not permitted  <-- matches the log byte for byte

Every OS-level source is correct in a process spawned by the extension, so the reversal is introduced inside the extension, not by the environment:

env.USERNAME            "דור"            5d3 5d5 5e8
env.USERPROFILE         "C:\Users\דור"   ... 5d3 5d5 5e8
env.HOMEPATH            "\Users\דור"     ... 5d3 5d5 5e8
os.userInfo().username  "דור"            5d3 5d5 5e8
os.userInfo().homedir   "C:\Users\דור"   ... 5d3 5d5 5e8
os.homedir()            "C:\Users\דור"   ... 5d3 5d5 5e8

correct  דור = 5d3 5d5 5e8
reversed רוד = 5e8 5d5 5d3

The failing path has no subdirectory component, which points at the global config write (path.join(homeDir, '.claude.json') followed by mkdir(path.dirname(target), {recursive:true})) — the dirname is the home directory itself.

The reversal looks like logical-to-visual bidi reordering applied to a string that is subsequently used as a filesystem path.

Regression

Working directory of the logs shows this is recent:

| VS Code log session | apply_settings | EPERM |
|---|---|---|
| 2026-09-10 | 2 | 0 |
| 2026-09-15 | 7 | 25 |

Model switching worked on the extension version running on 2026-09-10. It broke with 2.1.270 (installed 2026-09-14) and is still broken in 2.1.272.

Possibly the same underlying class of bug as #4003 (Hebrew/Arabic path characters swapped on macOS), though that one was a transliteration and this one is a reversal.

Workaround

Setting CLAUDE_CONFIG_DIR to an ASCII path avoids it, since bidi reordering is a no-op on ASCII. On Windows the 8.3 short name of the profile folder works without moving any data:

# C:\Users\CB63~1 is the 8.3 short name of C:\Users\דור
[Environment]::SetEnvironmentVariable('CLAUDE_CONFIG_DIR', 'C:\Users\CB63~1\.claude', 'User')

Note that this also relocates the global config from %USERPROFILE%\.claude.json to <CLAUDE_CONFIG_DIR>\.claude.json, so the existing file has to be copied over.

Environment

• OS: Windows 11 Home 10.0.26200
• VS Code extension: 2.1.272 (broken), 2.1.270 (broken), version running 2026-09-10 (working)
• Claude Code CLI: 2.1.195
• Node: v24.19.0
• Username: דור (Hebrew, RTL); profile folder C:\Users\דור exists and is correct on disk