[BUG] Windows: managed settings in HKLM registry fail to parse when JSON contains Shift_JIS "dame-moji" characters (2nd byte 0x5C)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On a Japanese-locale Windows machine (system ANSI code page 932), Claude Code refuses to start when the managed settings value in HKLM\SOFTWARE\Policies\ClaudeCode\Settings contains certain Japanese characters.

~~~
Registry: HKLM\SOFTWARE\Policies\ClaudeCode\Settings: Managed settings document could not be parsed as a JSON object; none of its settings are in effect. Fix or remove it.
~~~

The registry value itself is valid JSON. PowerShell's ConvertFrom-Json parses the exact same value without error. Only Claude Code fails.

Root cause

The failing characters are all Japanese "dame-moji" — characters whose Shift_JIS / CP932 encoding has 0x5C as its second byte. 0x5C is ASCII backslash.

Example: 貼 (U+8CBC) encodes to 0x93 0x5C in CP932.

When Claude Code reads the registry, the value appears to be decoded using the system ANSI code page rather than as Unicode. The trailing 0x5C is then interpreted as the start of a JSON escape sequence, producing an invalid escape and causing JSON.parse to throw.

Other affected characters include ソ, 十, 表, 能, 予, 構, 欺, 圭, 蚕, 申, 曾, 暴, 禄 and roughly 30 others.

This is consistent with #65691, which documented that Claude Code spawns reg.exe:

~~~
reg.exe query HKLM\SOFTWARE\Policies\ClaudeCode /v Settings
~~~

Reading reg.exe stdout through an ANSI code page would produce exactly this behaviour.

Impact

• Claude Code becomes completely unusable — it refuses to start.
• The entire managed policy is silently dropped. For an enterprise deployment this means all permissions deny rules, audit hooks, and MCP restrictions stop being enforced. A single character in an unrelated field disables the whole security policy.
• The error message points at the registry value, but the value is valid JSON — so administrators are led to debug the wrong thing.
• Any organisation deploying a Japanese-language claudeMd via Group Policy or Intune will hit this. 貼り付ける ("to paste") is an extremely common word.
• chcp 65001 does not work around it.

What Should Happen?

The registry value should be read as Unicode (e.g. via RegQueryValueExW, or by decoding reg.exe output as UTF-16LE) so that any valid JSON string parses correctly regardless of the system locale.

{"claudeMd":"貼"} is valid JSON and should load without error, exactly as {"claudeMd":"あ"} already does.

Error Messages/Logs

Registry: HKLM\SOFTWARE\Policies\ClaudeCode\Settings: Managed settings document could not be parsed as a JSON object; none of its settings are in effect. Fix or remove it.

Steps to Reproduce

Environment: Windows with system ANSI code page 932 (Japanese locale).

1. Write the minimal failing value (elevated PowerShell):

~~~powershell
New-Item -Path "HKLM:\SOFTWARE\Policies\ClaudeCode" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\ClaudeCode" -Name Settings -Value '{"claudeMd":"貼"}' -Type String
~~~

2. Confirm the stored value is valid JSON:

~~~powershell
(Get-ItemProperty "HKLM:\SOFTWARE\Policies\ClaudeCode").Settings | ConvertFrom-Json
~~~

Parses without error.

3. Run Claude Code:

~~~
claude -p test
~~~

Fails with the error above.

4. Control test — replace with a non-dame-moji character:

~~~powershell
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\ClaudeCode" -Name Settings -Value '{"claudeMd":"あ"}' -Type String
~~~

~~~
claude -p test
~~~

Works. あ is 0x82 0xA0 in CP932 — no 0x5C.

The only difference between step 3 and step 4 is whether the second byte of the character's CP932 encoding is 0x5C.

5. chcp does not help:

~~~
chcp 65001
claude -p test
~~~

Still fails. The console code page is irrelevant; the decoding appears tied to the system ANSI code page (HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage → ACP 932).

Workaround

Escaping all non-ASCII as \uXXXX before writing makes the stored value pure ASCII, which survives the ANSI round-trip:

~~~powershell
$o = Get-Content settings.json -Raw -Encoding UTF8 | ConvertFrom-Json
$j = $o | ConvertTo-Json -Depth 20 -Compress
$ascii = -join ($j.ToCharArray() | ForEach-Object {
if ([int]$_ -gt 126) { '\u{0:x4}' -f [int]$_ } else { $_ }
})
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\ClaudeCode" -Name Settings -Value $ascii -Type String
~~~

Workable, but non-obvious and undiscoverable from the error message.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.266 (Claude Code)

Platform

Other

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Platform note: selected "Other" — this is a Claude subscription (claude.ai) login via forceLoginMethod: "claudeai", not an API platform.

Reproduces in every environment tested: the VS Code extension, Git Bash, PowerShell 5.1, and cmd. The VS Code extension surfaces it as a startup failure:

~~~
Error: Claude Code process exited with code 1. stderr: ... Registry: HKLM\SOFTWARE\Policies\ClaudeCode\Settings: Managed settings document could not be parsed as a JSON object; none of its settings are in effect. Fix or remove it.
~~~

System locale:

~~~
HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage
ACP = 932
OEMCP = 932
~~~

How this was isolated: a real managed policy (~4,600 chars, Japanese claudeMd) failed to load. Bisecting the claudeMd string narrowed the failure to a single character at index 757 — 貼, the first character of 貼り付ける. Scanning all 817 characters of that string for ones whose CP932 encoding contains 0x5C returned exactly one hit, matching the bisection result precisely.

Related: #65691 documents reg.exe query HKLM\SOFTWARE\Policies\ClaudeCode /v Settings being spawned by claude.exe, which is where the ANSI decoding most likely occurs.

Secondary suggestion: the error message could include the byte offset at which JSON.parse failed. The current message says the document "could not be parsed as a JSON object", which led to a long investigation of the JSON itself — but the JSON was valid the whole time. An offset would have pointed at the corrupted escape immediately.

Note on the debug log: the VS Code extension's stderr includes two Broken symlink or missing file encountered for settings.json at path: C:\Program Files\ClaudeCode\managed-settings.json lines. These are benign (no such file was deployed; the policy is registry-only), but they appear immediately above the real error and read like a cause. Downgrading them to a quieter level, or omitting them when the file is simply absent, would reduce noise.