[BUG] Claude Code desktop ignores permission configurations for WSL projects, requiring approval for every file operation despite proper settings

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/29574
2. https://github.com/anthropics/claude-code/issues/36192
3. https://github.com/anthropics/claude-code/issues/37181

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

I run Claude Code on WSL2 daily and can share what works:
Root cause: Claude Desktop on Windows accesses WSL paths via \\wsl$\ mount. The permission system likely doesn't resolve WSL paths correctly, so glob patterns in settings.json never match.
Workaround — use CLI instead of Desktop:

npm install -g @anthropic-ai/claude-code
claude --dangerously-skip-permissions

The CLI version runs natively in WSL and resolves paths correctly. Permission settings in ~/.claude/settings.json (WSL-side) work as expected.
If you need Desktop specifically, try setting permissions with the Windows-style path:

{
  "permissions": {
    "allow": [
      "Edit(//wsl$/Ubuntu/**)",
      "Write(//wsl$/Ubuntu/**)",
      "Read(//wsl$/Ubuntu/**)"
    ]
  }
}

Note the //wsl$/ prefix — this is how Windows sees WSL paths. Your distro name may differ (Ubuntu, Debian, etc.).
Alternative — PreToolUse hook auto-approve:

INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')
if echo "$FILE" | grep -qE '^(/home/|/tmp/|/var/)'; then
    echo '{"decision":"approve"}'
fi
exit 0

This auto-approves file operations on standard WSL paths regardless of how Desktop resolves them.

This bug is specifically about Claude code desktop, there are reasons to
use Claude code desktop over the cli.

On Sat, Mar 21, 2026, 12:40 p.m. ゆる草 @.***> wrote:

yurukusa left a comment (anthropics/claude-code#37192) <https://github.com/anthropics/claude-code/issues/37192#issuecomment-4104124132> I run Claude Code on WSL2 daily and can share what works: Root cause: Claude Desktop on Windows accesses WSL paths via \\wsl$\ mount. The permission system likely doesn't resolve WSL paths correctly, so glob patterns in settings.json never match. Workaround — use CLI instead of Desktop: npm install -g @anthropic-ai/claude-code claude --dangerously-skip-permissions The CLI version runs natively in WSL and resolves paths correctly. Permission settings in ~/.claude/settings.json (WSL-side) work as expected. If you need Desktop specifically, try setting permissions with the Windows-style path: { "permissions": { "allow": [ "Edit(//wsl$/Ubuntu/)", "Write(//wsl$/Ubuntu/)", "Read(//wsl$/Ubuntu/**)" ] } } Note the //wsl$/ prefix — this is how Windows sees WSL paths. Your distro name may differ (Ubuntu, Debian, etc.). Alternative — PreToolUse hook auto-approve: INPUT=$(cat) FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')if echo "$FILE" | grep -qE '^(/home/|/tmp/|/var/)'; then echo '{"decision":"approve"}'fiexit 0 This auto-approves file operations on standard WSL paths regardless of how Desktop resolves them. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/37192?email_source=notifications&email_token=AAHU46DT4FB7XEDV2JAYSND4R3V3LA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJQGQYTENBRGMZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4104124132>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHU46APVENIMSQUSWDFG5T4R3V3LAVCNFSM6AAAAACW2GGWNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMBUGEZDIMJTGI> . You are receiving this because you authored the thread.Message ID: @.***>

Similar reported bug - https://github.com/anthropics/claude-code/issues/11380#issuecomment-4104350262

Seems to be recent as of the last week or so.

Same issue happening here for me. I'm getting prompted every 5-10 seconds to approve an edit or write, even with permissions wide open.

How can this still be open and not assigned!? Claude on Windows Desktop with WSL unusable now since 3 days. It doesn't even recognize "allow for this session" acceptances. This needs to be fixed ASAP! @bcherny

+1 Please fix ASAP !

I run Claude Code on WSL2 daily and can share what works: Root cause: Claude Desktop on Windows accesses WSL paths via \\wsl$\ mount. The permission system likely doesn't resolve WSL paths correctly, so glob patterns in settings.json never match. Workaround — use CLI instead of Desktop:

This is just silly. There are features that the CLI does not support (chrome extension integration to name one right off the top of my head).

Saying "Don't use Claude Desktop" isn't a solution to the legitimate problem posed here; it's a work-around at best.

+1 worked fine for weeks and one day it stopped working and I need to confirm every permissions

Claude for Windows - Claude 1.1617.0 (8d6345) 2026-04-09T16:10:15.000Z
same
Model: Sonet 4.6 / Opus 4.6

I have the same problem and requiring CTRL + Enter just made it worse, got so ridiculous I have to put 2 objects on top of my keyboard to keep CTRL + Enter pressed so that I don't get 100 prompts despite having "Auto mode" or "Bypass" turned on.

It says this:
"Claude requested permissions to write to \\EXAMPLENETWORKDRIVE\frontend\src\pages\documents\pasteCleanup.ts, which contains a suspicious Windows path pattern that requires manual approval."

Ah also the option to Always Allow does not show up, I can only Allow Once. It's for File Edit permissions.

Some more context, my project folder is on a network drive so I would expect that ALL CHANGES inside the project folder would be automatically accapted. I could understand if it was outside the project folder but inside makes no sense.

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.