Feature Request: Permission mode for "investigate freely, prompt before modifying"

Problem

When using Claude Code for investigation or exploration tasks, I'm frequently interrupted by permission prompts for harmless read-only commands. For example, when asking Claude to check if MySQL is installed, I get prompted for:

dir "C:\Program Files\MySQL" 2>nul || dir "C:\Program Files (x86)\MySQL" 2>nul

This creates friction during the exploratory phase when Claude needs to gather context before making any changes.

Current Options Don't Fit This Use Case

| Mode | Behavior | Issue |
|------|----------|-------|
| default | Prompts for all Bash commands | Too many interruptions for read-only commands |
| plan | Blocks all Bash commands entirely | Can't even run dir or ls to investigate |
| bypassPermissions | Allows everything | No safety net for destructive operations |
| Manual allow list | Requires listing every safe command | Tedious, incomplete, and maintenance burden |

There's currently no mode that says "run read-only commands freely, but prompt before modifications." Plan mode blocks too much; other modes prompt too much or allow too much.

Proposed Solution

A permission mode (e.g., investigateFreely or promptBeforeWrite) that:

Auto-allows:

• Read, Glob, Grep (already auto-allowed in all modes)
• Non-mutating Bash commands: dir, ls, cat, type, head, tail, find, where, which, pwd, echo, git status, git log, git diff, git branch, npm list, pip list, etc.

Still prompts:

• Write, Edit, NotebookEdit
• Mutating Bash commands: rm, mv, cp, mkdir, touch, git commit, git push, git checkout, npm install, pip install, database writes, etc.

Why This Matters

The distinction between "investigate" and "modify" is a natural trust boundary. Users often want Claude to freely explore a codebase or system to understand context, but still want a checkpoint before any changes are made.

Common workflow:

1. Ask Claude to investigate an issue → should explore freely
2. Claude proposes a fix → should prompt before executing

Every prompt for a read-only command is a context switch that breaks flow. Over a session, this adds up significantly.

Prior Discussion

I'm aware of #2058 which was closed as not planned, with a hook-based workaround suggested. I'm opening this as a separate request because:

1. The hook workaround requires users to build and maintain their own safe-command classification - the very thing this feature should provide out of the box
2. This is a fundamental UX pattern (read=safe, write=prompt) that aligns with how users intuitively think about permissions
3. The current modes create a false choice between "constant interruptions" and "no safety net"