Desktop app ignores bypassPermissions on macOS — every tool call prompts, every session, for months
Environment
- Claude Code desktop app on macOS (Sequoia 15.3)
- Claude Opus 4.6 (1M context)
- Non-developer user (business owner using Claude Code for email triage, project management, database queries)
The problem
bypassPermissions is set at all three levels and has been for months:
~/.claude/settings.json:
{
"permissions": {
"defaultMode": "bypassPermissions"
}
}
Project .claude/settings.local.json:
{
"permissions": {
"defaultMode": "bypassPermissions",
"deny": ["Bash(rm -rf *)", "Bash(sudo *)"]
}
}
Worktree .claude/settings.local.json: Same as above.
Every Bash command, every Edit, every Write, every WebSearch prompts for permission. Every single session. There is no "sometimes works" -- it never works.
Impact
My typical morning routine involves ~30+ tool calls (database queries, email API calls, file writes, script execution). Each one prompts. That turns a 5-minute automated process into 20+ minutes of clicking "Allow". This has been happening for months across dozens of sessions.
I am not a developer. I use Claude Code as a business tool via the desktop app. I cannot switch to Terminal -- it is not a usable interface for my workflow. The desktop app is the only viable option, and it is broken.
What I have tried
- Set
bypassPermissionsin~/.claude/settings.json(user level) - Set
bypassPermissionsin.claude/settings.local.json(project level) - Set
bypassPermissionsin worktree.claude/settings.local.json - Verified all three files are correctly formatted JSON
- Revisited this issue 20+ times across sessions -- settings are always correct, app always ignores them
- The
--dangerously-skip-permissionsCLI flag works from Terminal but cannot be passed to the desktop app
Expected behaviour
Permission prompts should not appear when defaultMode is set to bypassPermissions, except for writes to protected directories (.git, .claude, .vscode, .idea) as documented.
Actual behaviour
Every tool call prompts regardless of settings. Bash, Edit, Write, WebSearch -- all prompt. Settings files are confirmed present and correctly formatted but have zero effect.
Related issues
#29026, #29214, #30953, #33336, #33993, #34923, #12604, #20536, #25503, #37029
17 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is NOT a duplicate. The linked issues describe the CLI. This is the Desktop app (Conductor), which has a different permissions pathway.
Additional impact not covered in those issues: background agents launched via the Agent tool also cannot get Bash permissions, even when the parent session has bypassPermissions set. This means any long-running background task (database migrations, code generation, file processing) fails silently because the agent cannot execute commands.
Today's session: 84+ permission prompts clicked manually. Two background agents launched and both failed immediately because they could not run Bash. The permissions bug is not just an inconvenience — it breaks the agent architecture entirely.
Environment: macOS Sequoia 25.3.0, Claude Code desktop app, Opus 4.6, bypassPermissions set at user, project, and worktree level. All three settings files verified correct JSON.
Not a duplicate. This report includes specific diagnostic detail not present in the linked issues: the bug is worse in the desktop app than CLI, parallel tool calls bypass permissions while sequential calls do not, and the 4.6 update introduced new permission prompts (WebSearch) that were previously silent. These are distinct observations that may help pinpoint the root cause.
Daily update — 25 March 2026
Another full day lost to this. Summary:
I suspect this is disproportionately affecting Claude Code app users (as opposed to Terminal/IDE users) who run long sessions with background agents. We're a non-developer business user running Claude Code for operations and the permissions bug makes background agents completely non-functional.
The suggested fix remains simple: when resolving
bypassPermissions, ensure it applies consistently across all tool calls in a session, including those made by background agents.Day 2. Desktop app on macOS still ignoring
bypassPermissionsin settings.json. Every tool call still prompts. No workaround available for desktop app users.Day 4. Desktop app on macOS still ignoring
bypassPermissionsin settings.json. Every tool call still prompts. No workaround available for desktop app users.Day 4. Desktop app on macOS still ignoring
bypassPermissionsin settings.json. Every tool call still prompts. No workaround available for desktop app users.Day 5. Desktop app on macOS still ignoring
bypassPermissionsin settings.json. Every tool call still prompts. No workaround available for desktop app users.Day 6. Desktop app on macOS still ignoring
bypassPermissionsin settings.json. Every tool call still prompts. No workaround available for desktop app users.Day 15. Still broken on macOS desktop app (v2.1.87).
We have now tested all three permission bypass mechanisms. None work:
Every tool call still prompts. This is a daily productivity hit — we estimate 50-100 unnecessary permission clicks per working day.
The only partial workaround remains batching parallel tool calls in a single message, which sometimes bypasses the prompt.
Related issues from other users experiencing the same family of bugs: #40463 #42975 #38372 #36624 #40343 #42711 #40182
This appears to be a systemic permissions architecture issue, not an edge case.
To clarify: this is the Claude Code desktop app (not the CLI in Terminal). We do not use Terminal at all. All interaction is through the Claude Code desktop application on macOS.
Same on windows. Bypass just doesn't work. Also the desktop app, not in terminal.
can confirm bypass it not working in mac app
Same here. Not renewing Max until this is fixed.
same
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.