[BUG] Malformed settings.json files are silently skipped if they become incorrect after session startup.

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?

When starting claude CLI, a malformed .claude/settings.json file is correctly flagged and the user is warned.

But if .claude/settings.json is edited during a session and becomes malformed, it is silently ignored. This goes for both syntax errors, AND deviations from schema.

This leads to hooks and permissions not being correctly enforced, which can cause security problems for the user.

What Should Happen?

The CLI tool should display some kind of warning, and prompt the user to explicitly proceed.

Error Messages/Logs

Steps to Reproduce

STEP 1: Create a new project directory with the following structure

.
├── .claude/
│   └── settings.json
├── forbidden.md
└── permitted.md

with .claude/settings.json:

{
    "permissions": {
        "allow": [
            "Read(./permitted.md)"
        ],
        "deny": [
            "Read(./forbidden.md)"
        ],
        "defaultMode": "dontAsk"
    }
}

STEP 2: run claude CLI tool. There should be no problem at startup. Ask Claude to read the two files. Claude should report back that it can read permitted.md and not forbidden.md.

STEP 3: edit .claude/settings.json to introduce a trailing comma (not allowed per JSON spec) for instance in the "deny" list:

{
    "permissions": {
        "allow": [
            "Read(./permitted.md)"
        ],
        "deny": [
            "Read(./forbidden.md)",
        ],
        "defaultMode": "dontAsk"
    }
}

This error is subtle and difficult for a human to notice, the file looks superficially correct.

This is a minimal example, but even if the JSON is syntactically correct, failing to follow the schema, e.g. when specifying a hook, will produce the same behavior.

STEP 4: Ask Claude to read the two files again. Claude should report back that it can read both permitted.md and forbidden.md.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.98 (Claude Code)

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

• Issue #12468 seems to be a narrower case of similar behavior
• Issue #44631 is a different problem, with a similar scope.
• Issue #24823 complains of a similar problem but framed as a feature request.

Review from claude:

All three are related but narrower than #49834. Here's how they compare:                                                                                              
                                                                                                                
  #12468 — Closest to the core problem. Documents that a syntactically valid but semantically invalid permission pattern (wrong syntax like Bash(mkdir*)) causes the    
  entire settings file to be silently rejected. Closed as "not planned" after 60 days of inactivity. This directly supports the broader scope of #49834 — it            
  demonstrates the silent failure extends beyond malformed JSON to schema/syntax errors within the file. Worth citing explicitly in #49834.                             
                                                                                                                                                                        
  #44631 — A different but related failure mode: active sessions silently strip externally-added keys (like hooks) by overwriting the file from their in-memory state.  
  Closed as duplicate of #41259. This is actually a separate silent failure vector — not malformed settings being ignored, but valid settings being actively destroyed
  by the running session. Tangentially related but probably not a true duplicate of #49834.

  #24823 — Covers malformed JSON at startup causing silent fallback to Anthropic account login instead of a clear error, specific to Bedrock users. Closed same day it
  was opened (likely auto-closed). This confirms that startup does not always "correctly flag and warn" as claimed in #49834's description — it may silently degrade in
  a different way depending on context, which undermines that claim.

  Summary for #49834: The issue is not a duplicate of any of these — it is broader in scope than all three. However, #12468 and #24823 together provide evidence that
  the problem class is wider than the reproduction steps show, and #24823 specifically calls into question the issue's claim that startup correctly warns users.

This is a BUG. It magnifies small user errors into potential catastrophic problems.