[BUG] Claude Code sets ~/.claude.json to read-only (444), then hangs on startup because it can't write to it

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?

Claude Code sets its own config file (~/.claude.json) to read-only permissions (100444) during a session, then cannot start again because it can't write to the file. This effectively bricks Claude Code with no error message — the CLI hangs silently at startup.

The trust dialog ("Do you trust this folder?") renders correctly, but selecting "Yes" leads to a frozen CLI that cannot be interrupted with Ctrl+C — only closing the terminal ends the process.

Three distinct bugs

1. Claude Code set its own config file to 444 (read-only). This happened during a session where Claude Code was modifying configuration. The exact mechanism is unclear, but the result is that Claude Code bricked itself.

1. Silent hang instead of error message. When ~/.claude.json is unwritable, Claude Code should fail fast with a clear error. Instead it loops on EPERM errors invisibly and presents a frozen UI.

1. The write path preserves the broken permissions. The debug log shows Preserving file permissions: 100444 — Claude Code copies the read-only permission onto each temp file before attempting the rename. This means even if a write somehow succeeded, the file would remain read-only, guaranteeing the next write also fails. The write path should never preserve 444 on a config file it needs to be writable.

What Should Happen?

1. Claude Code should never set ~/.claude.json to read-only — it's a config file it needs to write to on every startup
2. If a write fails with EPERM, Claude Code should display a clear error message and exit gracefully, e.g.:

> Error: Cannot write to ~/.claude.json (Permission denied). Please check file permissions.

Error Messages/Logs

Claude Code silently loops on EPERM errors. From the debug log:


[DEBUG] Preserving file permissions: 100444
[DEBUG] Temp file written successfully, size: 31481 bytes
[ERROR] Failed to write file atomically: Error: EPERM: operation not permitted, rename '...' -> 'C:\Users\jpdre\.claude.json'
[DEBUG] Falling back to non-atomic write for C:\Users\jpdre\.claude.json
[DEBUG] Non-atomic write also failed: Error: EPERM: operation not permitted, open 'C:\Users\jpdre\.claude.json'
[ERROR] Failed to save config with lock: Error: EPERM: operation not permitted, open 'C:\Users\jpdre\.claude.json'


This pattern repeats many times during startup. The UI never displays any error.

Steps to Reproduce

The exact trigger is unclear, but in my case:

1. Claude Code was attempting to diagnose/fix a SessionEnd hook issue during a session
2. The session ended abnormally
3. All subsequent launches of Claude Code hang indefinitely

To reproduce the hang directly:

# Simulate what Claude Code did to itself
chmod 444 ~/.claude.json

# Launch Claude Code
claude

1. Trust dialog appears
2. Select "Yes, I trust this folder"
3. CLI hangs indefinitely — no prompt, no error message, no input accepted
4. Only closing the terminal ends the process

Fix: chmod 644 ~/.claude.json

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.59

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Diagnosis difficulty

This took over an hour to diagnose because:

• No error message is shown to the user
• The --debug flag itself fails with Error: Input must be provided either through stdin or as a prompt argument when using --print (presumably because it can't write state and falls into a broken code path)
• The symptoms (silent hang, trust dialog works but accept doesn't proceed) point in completely wrong directions — hooks, MCP servers, env variables, corrupted binary, etc.
• Only reading the debug log file (~/.claude/debug/latest) after the hang revealed the EPERM errors

Related Issues

• #28842 — Concurrent config writes corrupt .claude.json on Windows startup (same EPERM / atomic write pattern, different trigger)
• #29036 — Race condition: .claude.json corruption on Windows with concurrent sessions

These are all symptoms of .claude.json write fragility on Windows. This issue is distinct because it involves the file being set to read-only by Claude Code itself, causing a permanent bricked state rather than a transient corruption.

This bug report was generated by Claude Opus 4.6.