[BUG] Config lock path collides with home directory on Windows domain user profiles

[BUG] Config lock path collides with home directory on Windows domain user profiles

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, when a domain user's home directory follows the username.DOMAIN naming convention (e.g. C:\Users\jdoe.CORP), Claude Code's atomic config lock mechanism generates a lock path that collides with the user's actual home directory.

The lock path is constructed as:

parent(homedir) + "\" + username + "." + hostname

With:

• homedir = C:\Users\jdoe.CORP
• username = jdoe
• hostname = CORP

This produces:

C:\Users\ + jdoe + . + CORP = C:\Users\jdoe.CORP

...which is the user's actual home directory. mkdir on an existing directory throws EEXIST, the lock fails, and every config save attempt during startup fails silently, looping dozens of times before continuing.

This is a standard Windows Active Directory / domain profile layout where the local account is jdoe and the domain account home is jdoe.DOMAIN.

Environment

• Platform: Native Windows (claude.exe)
• Claude Code version: 2.1.69
• OS: Windows 11
• Terminal: PowerShell / Windows Terminal
• Profile type: Domain user — home directory at C:\Users\<username>.<DOMAIN>

Steps to Reproduce

1. Set up a Windows machine joined to a domain where the domain is the same as the hostname
2. Log in as a domain user whose home directory is C:\Users\<username>.<HOSTNAME>
3. Run claude from any directory
4. Observe repeated EEXIST errors in ~/.claude/debug/latest

Error from Debug Log

[ERROR] Failed to save config with lock: Error: EEXIST: file already exists, mkdir 'C:\Users\jdoe.CORP'
[ERROR] Error: Error: EEXIST: file already exists, mkdir 'C:\Users\jdoe.CORP'
    at mkdirSync (unknown)
    at mkdirSync (B:/~BUN/root/src/entrypoints/cli.js:12:3048)
    at d38 (B:/~BUN/root/src/entrypoints/cli.js:6483:5856)
    at IA (B:/~BUN/root/src/entrypoints/cli.js:6483:4432)
    at CnA (B:/~BUN/root/src/entrypoints/cli.js:4296:584)
    at processTicksAndRejections (native:7:39)

This error repeats ~10–15 times during every startup. Config changes (trust decisions, permission updates, session state) are silently lost.

Expected Behavior

The lock mechanism should not generate a path that could collide with an existing directory. Options:

• Use a subdirectory inside homedir for locks (e.g. ~/.claude/.locks/) instead of a sibling to homedir
• Use a temp file path (e.g. os.tmpdir()) for lock directories
• Check whether the generated lock path already exists as a directory and fall back gracefully before attempting mkdir

Actual Behavior

EEXIST is thrown on every mkdir call for the lock path. Errors are swallowed and the operation fails silently. The startup sequence continues but all config writes during the session are dropped, including trust decisions — which causes a secondary symptom where the trust dialog appears to accept input but the trust state never persists.

Additional Context

A local (non-domain) user profile C:\Users\jdoe also exists on the same machine, which is what likely led to this path being chosen as the lock target — CC appears to be using the parent of the home directory (C:\Users\) + computed suffix (jdoe.CORP), treating it as a safe scratch location.

The secondary symptom (TUI input freeze / trust dialog with no working selection) may be a separate issue but is consistently reproducible on this environment alongside the EEXIST errors.