claude-code - 💡(How to fix) Fix [Bug] Auto-accept mode ignores directory containment check for home paths ending in period

Bug Description Title: Auto-accept ("accept edits on") still prompts for in-workspace edits when the home directory name ends in a period

Environment:

• Claude Code v2.1.158
• macOS (Darwin 24.6.0), Apple Silicon
• Home directory name ends in a literal period, e.g. /Users/name.
• Clean config: no ask permission rules, no hooks, no managed/enterprise settings, no active plugin hooks

Summary: With permission mode set to accept edits on, Edit/Write operations on files inside the current working directory still trigger a permission prompt — but only when the working directory resolves under a home path whose final component ends in a period (.). Identical operations under a dot-free path apply silently as expected.

Steps to reproduce:

1. On an account whose home dir name ends in a period (e.g. short name name. → home /Users/name.), start Claude Code in a directory under it.
2. Shift+Tab to accept edits on (footer confirmed on).
3. Ask Claude to edit a file inside the cwd.
4. Actual: a permission prompt appears anyway.
5. Expected: the edit applies silently (it's inside the trusted cwd, in accept-edits mode).

Controlled evidence:

• cwd under trailing-dot home, file inside cwd, accept-edits on → prompts (reproduced repeatedly, footer verified on at prompt time).
• Separate session in /private/tmp/aa-test (no trailing dot), same mode, file inside cwd → silent (correct).
• Only material difference between the two = the trailing-dot home component.

Symlink test (rules out a user-side fix):

• Created /Users/Shared/Developing (dot-free) symlinked to the real /Users/name./Documents/Developing, and ran/edited through the clean path. Still prompts.
• Conclusion: the harness canonicalizes/realpath-resolves the edit target before the accept-edits directory-containment check, so the matcher always sees the trailing-dot real path. No symlink/alias can route around it, and the dot is in the home-dir name itself.

Suspected cause: the trusted-directory containment check (after realpath resolution) mishandles a path component ending in .. OS-level path handling is consistent (the dot is preserved by pwd -P, realpath, stat), so the defect is in Claude Code's path/containment logic, not the filesystem.

Impact: auto-accept is effectively unusable for any user whose macOS short name ends in a period (commonly auto-generated from a full name ending in an initial).

Environment Info

• Platform: darwin
• Terminal: WezTerm
• Version: 2.1.156
• Feedback ID: fae72945-4b5d-40e2-b02d-5bf4e3d40729

Errors

[]