[BUG]

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?

Summary

Three issues with the permission settings system that combined to make the
bypassPermissions escape hatch unreliable in practice during a long
overnight session.

1. settings.json permissions block replace, not merge

Setting permissions.defaultMode: "bypassPermissions" at the user level
(~/.claude/settings.json) is silently ignored if ANY higher-precedence
settings file (project .claude/settings.json or .claude/settings.local.json)
contains a permissions block — even one that only defines
permissions.allow.

Expected: per-key merge so that defaultMode set anywhere in the
hierarchy applies unless explicitly overridden.

Actual: the entire permissions block from the highest-precedence file
that defines it wins, silently dropping defaultMode settings from
lower-precedence files.

This is a footgun because users naturally set defaultMode once at the
user level expecting it to apply globally, and a project-level allowlist
silently disables it.

2. settings.local.json auto-rewriter strips defaultMode

When the user approves a prompt with "always allow," Claude Code rewrites
.claude/settings.local.json to add the new entry to permissions.allow.
Observed during this session: the rewriter dropped a previously-set
permissions.defaultMode: "bypassPermissions" field. Adding it back
manually fixed it temporarily but it was at risk of being stripped again
on the next auto-write.

3. Running chats can't pick up settings changes

Settings changes only apply to NEW sessions. There's no in-session way
to elevate a running chat to bypassPermissions mode. If you start a long
chat in default mode and discover mid-flight that the prompts are
disruptive (e.g., you want to walk away overnight), the only option is
to commit work-in-progress, close the chat, and reopen — risky if the
chat is mid-phase with uncommitted state.

A /permissions set bypassPermissions (or similar) slash command that
takes effect immediately in the current session would solve this.

Combined impact

The three issues compounded over a 6-hour session: bypass was set but
silently disabled, the running chat couldn't be fixed mid-flight, and
the workaround (close + reopen) risked losing in-flight code work. Net
result was hundreds of permission prompts during a session that the user
had explicitly configured to skip them.

Suggested fixes

• Per-key merge for the permissions block (defaultMode + allow merge

independently across hierarchy levels).

• settings.local.json auto-rewriter must preserve defaultMode and other

non-allow keys when adding new entries.

• In-session /permissions mutation command (or auto-reload settings on

file change for the active session).

• Optionally: visible warning at session start when a higher-precedence

permissions block is overriding lower-precedence settings.

What Should Happen?

ALLOW A USER TO STOP THE UNGODLY "ALLOW" PROMPTS HOLY HELL THEY ARE THE WORST THINGS EVER AND WHOEVER WROTE THEM INTO CODE SO FIRMLY SHOULD BE FORCED TO LISTEN TO TAYLOR SWIFT ON REPEAT FOR THE REST OF THEIR LIVES

Error Messages/Logs

Steps to Reproduce

TAYLOR SWIFT SONGS FOR LIFE

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

OPUS 4.7

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_