Desktop app: bypassPermissions mode still prompts for confirmation

[ylytdeng]

Description

On the Claude Code Desktop app (Windows 11), setting permissions.defaultMode to "bypassPermissions" in both global and project settings still prompts for confirmation on every tool use (Edit, Write, Bash, etc.).

Steps to Reproduce

1. Set ~/.claude/settings.json:

{
  "permissions": {
    "allowedModes": ["default", "acceptEdits", "plan", "bypassPermissions"],
    "defaultMode": "bypassPermissions"
  }
}

2. Also set .claude/settings.local.json in the project:

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}

3. Restart the Claude Code Desktop app
4. Use Shift+Tab to confirm the mode is set to bypass/auto
5. Try any tool use (e.g., Edit a file)

Expected Behavior

Tools should execute without prompting for confirmation.

Actual Behavior

Every tool use still shows a confirmation prompt that requires clicking to approve.

Environment

• App: Claude Code Desktop (Windows)
• OS: Windows 11 Home China 10.0.26200
• Shell: bash (WSL)
• Working directory: WSL path (\wsl$\Ubuntu\home\...)

Notes

• Both global (~/.claude/settings.json) and project-level (.claude/settings.local.json) configs have "defaultMode": "bypassPermissions" set correctly
• The UI mode selector also shows the correct mode
• Issue persists after app restart

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude Code desktop ignores permission configurations for WSL projects, requiring approval for every file operation despite proper settings #37192
2. Desktop App: permission prompts still appear despite bypass permissions mode enabled #42428
3. [BUG] bypassPermissions not working on Windows/WSL — still prompts for Edit/Write #37941

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]

We are experiencing the same issue on macOS desktop app. We have tested all three bypass mechanisms (bypassPermissions, allow list, PreToolUse hook) — none work. Every tool call prompts. 15 days and counting.

Tracking our experience in detail at #38662, which also links to other related reports. This appears to be a systemic permissions architecture issue affecting multiple platforms.

[jgodboutPCS]

I am having a similar issue, but not getting confirmation on all prompts. I notice that when I run a skill, the permissions setting reverts back to accept edits on its own and does not stay in bypass permissions on mode. I have to continuously shift-tab to reset it back to the correct mode. However, while in this mode it does work (most of the time).

[houserooms]

Interesting data point about skills resetting the permissions mode. We see a different symptom on macOS desktop app — bypassPermissions never takes effect at all, regardless of how it's set. No skill trigger needed.

Between the three of us on this thread: one where it resets on skill use, one where it never works. Same underlying permissions architecture bug, different manifestations.

Details and cross-references to other affected users at #38662.

[iamseanmillare]

I'm experiencing the same issue. I have defaultMode: "bypassPermissions" set in settings.json and also added the target folder via /add-dir as a working directory — prompts still appear.

Additional context: I'm using the RTK plugin on top of Claude Code. As a temporary workaround, I've been routing edits through a sub-agent and using rtk node -e to push edits via Bash command instead, since the permission prompt seems to be triggered specifically by the Edit tool — Bash commands appear to bypass it.

[Steviey]

+1 Rightsmanagement is an absolute mess. If this is security then...good luck!