[BUG] Claude is ignoring auto accept mode

Thank you for the bug report. We've identified the root cause: a Windows path handling bug in our permission system that was causing "accept edits on" mode to fail on Windows platforms. This regression was introduced in v1.0.103.

The fix has been included as part of v1.0.105. Please update to the latest version to resolve this issue.

Sorry for the trouble!

I'm experiencing the same issue. I have updated my code using npm install -g @anthropic-ai/claude-code, but that hasn't resolved the issue.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/7114
2. https://github.com/anthropics/claude-code/issues/7113
3. https://github.com/anthropics/claude-code/issues/7104

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'm experiencing the same issue. I have updated my code using npm install -g @anthropic-ai/claude-code, but that hasn't resolved the issue.

@supunlakmal Can you confirm you are on v1.0.105? claude -v

C:\>claude update
Current version: 1.0.105
Checking for updates...
Claude Code is up to date (1.0.105)

Still being repeatedly asked if allow to write to same directory. I can see duplicate entries being added to settings.local.json each time I answer yes:

{
  "permissions": {
    "allow": [
      "Read(/C:\\src\\Notes\\Blog/**)",
      "mcp__auzredevops__core_list_projects",
      "Read(/C:\\src\\Notes\\Topics/**)",
      "Read(/C:\\src\\Notes\\Topics/**)",
      "Read(/C:\\src\\Notes/**)",
      "Read(/C:\\src\\Notes\\Blog/**)",
      "Read(/C:\\src\\Notes\\Blog/**)",
      "Read(/C:\\src\\Notes\\Blog/**)",
      "Read(/C:\\src\\Notes\\Blog/**)"
    ],
    "deny": [],
    "ask": []
  }
}

The issue still persists. I have updated and cleaned the corrupted claude.local.json file, but still on the recommended version 105.

Claude Code has a Windows path bug - it keeps
adding paths with /C:\... instead of C:\... when
you approve permissions. This is why:

1. Even with "allow": ["*"] (allow everything),

it still prompts

1. When you approve, it adds the wrong format

path

1. The wrong format doesn't match, so it asks

again next time

Thanks for letting me know, working on a fix. In the meantime, if you need to work around this issue, you can temporarily downgrade to v1.0.102 where this functionality is working correctly.

ok thanks, also tried to disable permissions altogether. that didnt work either which indicates its a deeper issue. now checking the global settings file.

Still on the same version, but cleared all entries of the the allow array in my project's .claude/settings.json and .claude/settings.local.json, and restarted. Now it never asks for permission to read anything, just goes ahead. Asked me once if it was allowed to make edits and then never asked again and I can't see it saving that setting anywhere...

Hello, I have same problem since yesterday, right now im on 1.0.105 (Claude Code)

Should be fixed in 1.0.106. Please resubmit bug report if you continue having issues. Thanks!

I'm on 1.0.108 and problem is still present. Should I open a new bug?
Here a report:

Claude Code Permission System Bug Report

Date: 2025-09-06
Reporter: User experiencing permission request issues
Claude Version: Sonnet 4 (claude-sonnet-4-20250514)

Issue Description

Claude Code continues to request user permission for /tmp/** file operations despite having explicit auto-approval permissions configured in .claude/settings.local.json.

Configuration Details

File: .claude/settings.local.json
Original Configuration: Multiple redundant entries for Read(/tmp/**) (18 duplicate entries)
Cleaned Configuration:

{
  "permissions": {
    "allow": [
      "Bash(pandoc:*)",
      "Bash(python3:*)", 
      "Bash(find:*)",
      "Bash(mkdir:*)",
      "Read(/tmp/**)",
      "Write(/tmp/**)",
      "Edit(/tmp/**)",
      "WebSearch"
    ],
    "deny": [],
    "ask": []
  }
}

Expected Behavior

Claude Code should automatically approve all file operations in /tmp/** without requesting user permission.

Actual Behavior

Claude Code continues to ask for permission when attempting to read, write, or edit files in /tmp/ directory, despite the configuration.

Test Case: When asked to create /tmp/claude_code_permission_bug_report.md, Claude requested permission and user responded "yes, for this session" - confirming the auto-approval settings are being ignored.

Possible Root Causes

1. Cache/Reload Issue: Settings file changes not being properly loaded
2. Path Matching Bug: Permission pattern matching not working correctly for /tmp/**
3. Permission Precedence Bug: Permission evaluation logic malfunction
4. Duplicate Entry Issue: Multiple identical entries causing configuration conflicts

Reproduction Steps

1. Configure /tmp/** permissions in .claude/settings.local.json
2. Attempt any file operation in /tmp/ directory
3. Observe permission request despite auto-approval configuration

Impact

• Interrupts workflow with unnecessary permission requests
• Reduces efficiency when working with temporary files
• Creates user confusion about permission system functionality

Recommended Actions

1. Investigate permission pattern matching logic
2. Check settings file reload mechanism
3. Review permission evaluation precedence
4. Test with simplified configuration (single entry per permission type)

@paolonoli I believe this is a format issue. See https://docs.anthropic.com/en/docs/claude-code/iam#tool-specific-permission-rules. The rule should be "Read(//tmp/**)", "Edit(//tmp/**)" note there is no Write permission.

Thanks for reply, I agree with you but the file entries (like "Read(/tmp/**)",) have been written by claude-code (I've not edited it manually).

@paolonoli ask claude code to clean the settings file. you can ask it to then correctly add permissions after its cleaned the file. when the issue persisted there were corrupted or malformed entries made into the settings file. happened to everyone. this should hopefully resolve your issue.

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.