Desktop app ignores bypassPermissions on macOS — every tool call prompts, every session, for months

Resolved 💬 17 comments Opened Mar 25, 2026 by houserooms Closed May 24, 2026

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 bypassPermissions in ~/.claude/settings.json (user level)
  • Set bypassPermissions in .claude/settings.local.json (project level)
  • Set bypassPermissions in 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-permissions CLI 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

View original on GitHub ↗

17 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/29026
  2. https://github.com/anthropics/claude-code/issues/38148
  3. https://github.com/anthropics/claude-code/issues/34923

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

houserooms · 3 months ago

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.

houserooms · 3 months ago

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.

houserooms · 3 months ago

Daily update — 25 March 2026

Another full day lost to this. Summary:

  • ~84 permission clicks in a 2.5-hour session — one every 1.8 minutes
  • 4 background agents failed because they couldn't get Bash permission (see #38859)
  • A major database migration had to be done entirely in the main session because agents are useless without Bash
  • Parallel tool calls bypass the bug — discovered today that firing multiple Bash calls in one response skips the prompt, while sequential calls trigger it. This suggests the permission check is per-response, not per-session.
  • Mid-session, the prompts intermittently stop appearing, then restart unpredictably. New sessions always start broken.

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.

houserooms · 3 months ago

Day 2. Desktop app on macOS still ignoring bypassPermissions in settings.json. Every tool call still prompts. No workaround available for desktop app users.

houserooms · 3 months ago

Day 4. Desktop app on macOS still ignoring bypassPermissions in settings.json. Every tool call still prompts. No workaround available for desktop app users.

houserooms · 3 months ago

Day 4. Desktop app on macOS still ignoring bypassPermissions in settings.json. Every tool call still prompts. No workaround available for desktop app users.

houserooms · 3 months ago

Day 5. Desktop app on macOS still ignoring bypassPermissions in settings.json. Every tool call still prompts. No workaround available for desktop app users.

houserooms · 3 months ago

Day 6. Desktop app on macOS still ignoring bypassPermissions in settings.json. Every tool call still prompts. No workaround available for desktop app users.

houserooms · 3 months ago

Day 15. Still broken on macOS desktop app (v2.1.87).

We have now tested all three permission bypass mechanisms. None work:

  1. bypassPermissions in settings.json — ignored since day 1
  2. allow list in settings.local.json (with explicit Edit, Write, Read entries) — ignored
  3. PreToolUse hook returning permissionDecision: allow — ignored

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.

houserooms · 3 months ago

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.

gautamchandna · 3 months ago

Same on windows. Bypass just doesn't work. Also the desktop app, not in terminal.

oneart-dev · 3 months ago

can confirm bypass it not working in mac app

cbornBerlin · 3 months ago

Same here. Not renewing Max until this is fixed.

david-christ · 3 months ago

same

github-actions[bot] · 1 month ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

github-actions[bot] · 5 hours ago

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.