Race condition: concurrent writes corrupt ~/.claude.json, recovery loop with no backoff

Description

~/.claude.json got corrupted due to what appears to be concurrent writes from multiple Claude Code instances. After corruption, the recovery logic entered a tight retry loop (dozens of repeated error messages) with no backoff, requiring Ctrl+C to break out.

Steps to reproduce

1. Run multiple Claude Code instances simultaneously (normal workflow — CLI + IDE extension, multiple terminal tabs, etc.)
2. Config file gets corrupted — JSON parse error due to two JSON objects concatenated together ("Extra data" at parse boundary)
3. On next startup, Claude Code detects corruption and attempts recovery
4. Recovery enters a tight loop printing the same error message dozens of times without any backoff or circuit breaker

Error message (repeated dozens of times)

Claude configuration file at /Users/<user>/.claude.json is corrupted: JSON Parse error: Unable to parse JSON string
The corrupted file has been backed up to: /Users/<user>/.claude/backups/.claude.json.corrupted.<timestamp>
A backup file exists at: /Users/<user>/.claude/backups/.claude.json.backup.<timestamp>
You can manually restore it by running: cp "/Users/<user>/.claude/backups/.claude.json.backup.<timestamp>" "/Users/<user>/.claude.json"

Root cause analysis

• The corrupted file backup shows "Extra data" at the JSON parse boundary (two JSON objects concatenated) — classic concurrent write race condition
• The backup file referenced in the error message did not exist on disk, suggesting it was already overwritten by a newer backup
• Recovery loop has no backoff, max retry limit, or circuit breaker

Expected behavior

1. Concurrent writes to ~/.claude.json should be safe (file locking or atomic writes)
2. Recovery from corruption should either succeed or fail gracefully with a single clear message — not loop indefinitely

Environment

• macOS (Darwin 25.2.0)
• Claude Code v2.1.86
• Multiple instances running simultaneously (standard workflow)