Let users turn off every permission pop-up (bypass mode still prompts for computer use, Run In Terminal and over Remote Control)

More evidence: in bypass mode, most of my remaining pop-ups come from rm inside ordinary shell commands

I went through the Claude Desktop log (~/Library/Logs/Claude/main.log) for 18 to 26 Sep 2026. Every session involved was in bypassPermissions, both in the desktop's session record and in the CLI transcript.

• 35 permission pop-ups in that time. 22 of them were for the Bash tool.
• I matched each Bash pop-up to its command in the transcript. In 16 of the 22, the command included an rm. Typical examples:
• cd <scratch dir> && rm -f threads/* && python3 ...
• mkdir -p frames && rm -f frames/*; ffmpeg ...
• rm -f "$S"/*_old.png; ./shot.sh ...
• grep ... ; rm -rf ../../../oldcheck
• Most of these came from background subagents. Nobody was at the Mac. The work stopped until I tapped the pop-up on my phone, sometimes 20 minutes later and once after 4 hours. Several simply timed out ("Permission request ... aborted"), and the agent lost that step.

Repro (Claude Code 2.1.282, macOS 26, also happens in headless mode)

mkdir -p /tmp/elsewhere/threads && touch /tmp/elsewhere/threads/a
cd ~/some-project
claude -p --permission-mode bypassPermissions \
  "Run exactly: cd /tmp/elsewhere && rm -f threads/* && echo DONE"

Result: the call is denied (in the desktop app it becomes a pop-up) with:

This Bash command contains multiple operations. The following parts require approval: cd /tmp/elsewhere, rm -f threads/*

Expected: the command runs, because the session is in bypass permissions.

The target is a scratch folder, not a critical path. The same rm with a literal absolute path runs without a prompt. So the check fires because the parser can't place the relative glob after the cd, not because the removal is dangerous.

Why this should change

1. I chose this mode on purpose. I set defaultMode: "bypassPermissions", and I accepted the warning dialog that says I take responsibility. I'm the one accountable for what my agents do. A prompt I didn't ask for goes against that choice.
2. The name promises no prompts. "Bypass permissions" and --dangerously-skip-permissions both read as "never ask". The exceptions are only listed in a sub-section of the permission-modes page ("Actions no mode auto-approves", "Critical paths"). Nothing about them is shown where I pick the mode.
3. The prompt protects nothing for an unattended session. It doesn't stop a mistake, it only delays the step. I answer from my phone without seeing the context, and when I'm away the step just waits or times out. Hours of background work stall on a rm -f frames/*.
4. Subagents make it worse. A background subagent's pop-up reaches me with no view of the conversation that led to it, so I can't judge it anyway. I just tap Allow.
5. The false positives aren't rare. Agents write cd dir && rm -f x/* all the time. In my sessions this was the single biggest source of pop-ups after I had turned everything else off.

Asks

• Let bypass mode actually bypass the critical-path / compound-command rm check, or give it a setting such as permissions.bypassCriticalPathCheck: true, off by default if you prefer.
• At least don't flag a relative glob after a cd to an ordinary folder as critical. Resolve the path, or only flag it when the result really is a critical path.
• List every exception to bypass mode where the mode is chosen: in the desktop mode picker and in the warning dialog.

Workaround I'm using now (it works)

The docs say a PermissionRequest hook can answer these prompts. So I added one that returns {"decision":{"behavior":"allow"}} whenever permission_mode is bypassPermissions. It leaves AskUserQuestion and computer-use app grants alone. With it, the repro above runs with no denial. Every user who picks bypass shouldn't need a custom hook to get what the mode's name says.

One more case, the one that hurts most day to day.

Computer use over Remote Control still has to be accepted on the Mac itself. That defeats the point. If I'm driving a session from my phone, I'm by definition not at the computer, so nobody can click Allow, and the task stops. If I were at the computer, I wouldn't need Claude to control it remotely, and the pop-up would only interrupt what I'm doing there.

Under bypass permissions, a session started or driven through Remote Control should be able to use computer use without a confirmation on the Mac. If a confirmation must stay, it should be answerable from the phone.

Another case from today. I started a Desktop chat from the iOS app through Remote Control. It runs in Accept edits, and there's no option to choose Bypass from the phone. My Mac runs Bypass on purpose. Over about 30 minutes, every read-only command (Gmail reads, curl, web search, web fetch) needed its own "Allow once" tap on my phone, and I couldn't work. Please give phone-started chats a Bypass option when the machine's owner runs Bypass, or let a chat remember the permission setting it's given. Phone-started chats also refuse the home folder as a working folder. That should be my choice too.