[Bug] Auto-added Read/Edit permissions generate double-slash paths (//Users/... instead of /Users/...)

[developer-kanghyun]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

When Claude Code auto-adds a Read permission to ~/.claude/settings.json (after user approval during a session), the path is saved with a double-slash prefix.

Actual: Read(//Users/kanghyun/Desktop/project/open-claw-repo/**)
Expected: Read(/Users/kanghyun/Desktop/project/open-claw-repo/**)

This occurs on macOS with standard absolute paths — no symlinks or drive letters involved.

What Should Happen?

Auto-added Read/Edit permission rules should use a single-slash absolute path: Read(/Users/kanghyun/Desktop/project/**).

Error Messages/Logs

No error — the permission is silently saved with // prefix. The // rule still functions due to the v2.1.89 checker fix, but accumulates malformed entries over time.

// settings.json after auto-add
"allow": [
  "Read(//Users/kanghyun/Desktop/project/open-claw-repo/**)"
]

Steps to Reproduce

1. Start a new Claude Code session in a project directory
2. Ask Claude to read a file outside the current project (e.g., ~/.claude/settings.json)
3. Approve the Read permission when prompted
4. Check ~/.claude/settings.json — the auto-added entry has // prefix

This was reproduced multiple times during a single session. Each time a new Read permission was approved, the // prefix appeared.

Claude Model

claude-opus-4-6 (1M context)

Is this a regression?

Partially. CHANGELOG v2.1.89 mentions:

"Fixed Edit(//path/**) and Read(//path/**) allow rules to check the resolved symlink target"

This fix addressed checking existing // rules, but the generation of // paths during auto-add still occurs. Two separate issues:

1. ✅ Checking // rules against symlink targets (fixed in v2.1.89)
2. ❌ Generating // rules when auto-adding permissions (this issue — still occurs in v2.1.90)

Last Working Version

Unknown — the // generation may have existed before v2.1.89.

Claude Code Version

2.1.90

Platform

Anthropic Direct (claude.ai/code)

Operating System

macOS (Darwin 25.2.0)

Terminal/Shell

zsh (VSCode integrated terminal)

Additional Information

Note on suggested duplicates: The bot flagged #12175 and #5401 as duplicates, but those are Windows-specific path issues (WSL //c/mnt/c/ and Git Bash /c/c/ prefix). This issue is macOS-specific with a different root cause — an extra / is prepended to an already-absolute macOS path.

	Windows issues (#12175, #5401)	This issue
Platform	Windows (WSL/Git Bash)	macOS
Pattern	//c/mnt/c/Users/... or /c/c/...	//Users/kanghyun/...
Root cause	Drive letter path conversion	Absolute path gets extra / prefix
Status	Both CLOSED	Still occurs in v2.1.90

[github-actions]

Found 2 possible duplicate issues:

1. Windows: Invalid path format in Permission suggestions (//c/mnt/c/ prefix) #12175
2. Path Normalization Failure: Doubled Unix Drive Prefix in Windows Environments #5401

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

[developer-kanghyun]

Not a duplicate — different platform and root cause

The suggested duplicates are Windows-specific path normalization issues:

• Windows: Invalid path format in Permission suggestions (//c/mnt/c/ prefix) #12175: Windows WSL //c/mnt/c/ prefix
• Path Normalization Failure: Doubled Unix Drive Prefix in Windows Environments #5401: Git Bash /c/c/ drive letter doubling

This issue is macOS-specific with a different root cause:

	Duplicates (#12175, #5401)	This issue (#44106)
Platform	Windows (WSL/Git Bash)	macOS
Pattern	//c/mnt/c/Users/... or /c/c/...	//Users/kanghyun/...
Root cause	Drive letter path conversion	Absolute path gets extra / prefix
Status	Both CLOSED	Still occurs in v2.1.90

Live reproduction (just happened during this session)

Before cleanup — settings.json contained:

"Read(//Users/kanghyun/Desktop/project/open-claw-repo/**)"

This was auto-added by Claude Code v2.1.90 on macOS (Darwin 25.2.0) when approving a Read permission. The path /Users/kanghyun/Desktop/project/open-claw-repo/ is a standard macOS absolute path with no symlinks or drive letters involved.

Additional context from CHANGELOG

v2.1.89 CHANGELOG mentions:

"Fixed Edit(//path/**) and Read(//path/**) allow rules to check the resolved symlink target"

This fix made the checker handle existing // rules, but the generator still produces // paths on macOS. Two separate issues:

1. ✅ Checking // rules (fixed in v2.1.89)
2. ❌ Generating // rules (this issue — still occurs in v2.1.90)

[heidi-arcticrd]

Still reproducible on 2.1.141 (macOS 26.5).

After approving a Read permission prompt this session, the harness auto-wrote this entry to settings.local.json:

"Read(//Users/<user>/.claude/skills/<skill>/**)"

The double leading slash matches the OP's report exactly — standard macOS absolute path, no symlinks. Manually-authored entries in the same file (e.g. Read(/Users/<user>/.claude/**)) use a single slash and work as expected; the generator-side bug has been live for at least the ~5 weeks since this was filed.

Side observation that may or may not be the same root cause: in the same session I saw an Edit permission prompt fire for a path that should have been covered by an existing Edit(//Users/<user>/.claude/skills/<skill>/**) rule. Replacing the // with a single / in that rule silenced the prompt on re-run. I couldn't fully isolate whether that was the path mismatch or a separate "edit your own settings" guard, but worth checking whether the v2.1.89 checker fix covers Edit(//…) the way it covers Read(//…).

Env: claude-code 2.1.141, macOS 26.5 (Darwin 25.5.0), zsh.

[github-actions]

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