No way to enforce approval on all file modifications

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's permission system is one of its best features — it builds trust by letting users see and approve every change. But that trust breaks down when the tool modifies files outside those controls with no way to opt back in.

The core issue: there is no way to enforce "all file modifications require my approval." The permission model has blind spots that no combination of settings can close. Two examples:

Memory file paths are auto-allowed for Edit/Write

Edit and Write tool calls to ~/.claude/projects/*/memory/ complete without approval prompts, even when:

• No allow rule for these paths exists in any settings file (global, project, or local)
• autoMemoryEnabled is set to false

Bash commands to the same paths DO prompt for approval, confirming this is specific to Edit/Write.

This is particularly frustrating because memory files persistently shape agent behavior across sessions. Users who care enough to configure permissions carefully are exactly the users who want to know what's being written to memory.

(See also #34548 where we reported detailed findings.)

Built-in skills edit files with no visibility into what changes

Built-in skills like update-config, keybindings-help, simplify, tidy-readme, and statusline-setup modify files (settings.json, keybindings.json, code files, READMEs) through the Skill tool wrapper. The user sees "Skill(update-config)" but never sees the underlying Edit/Write calls or their content. There is no way to inspect what a skill will change before it executes.

For custom skills and MCP tools, PreToolUse hooks solve this beautifully — we use one to show colored diffs for Linear updates, for example. But built-in skills don't surface their internals the same way.

Workarounds

We built hooks to close both gaps:

1. autoMemoryEnabled: false + PreToolUse hook on Write|Edit that checks for memory paths and returns permissionDecision: "ask"
2. PreToolUse hook on Skill that returns permissionDecision: "deny" for opaque built-in skills, forcing use of Edit tool directly

These work, but the users who need them most are the ones who already trust the permission system to have their back.

Proposed Solutions

1. Memory file paths should respect the same permission rules as all other paths. If no allow rule exists, prompt for approval.
2. autoMemoryEnabled: false should fully restore normal permission gating on memory paths.
3. Built-in skills that edit files should surface their Edit/Write calls through the normal permission system, or provide a preview of changes before executing.

Environment

• Claude Code CLI
• macOS (Darwin 24.6.0)