[BUG] Claude Code updater silently fails to update `clause` symlink on non-privledged Windows accounts

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?

After Claude Code auto-updates on Windows, running claude from Git Bash fails with bash: claude: command not found, even though claude still works fine from PowerShell/cmd immediately afterward.

Root cause: Claude Code installs to ~/.local/bin/, with claude.exe (used by PowerShell/cmd, which auto-resolve .exe via PATHEXT) and a separate extensionless claude file (needed by Bash, which does not do extension resolution) that's meant to be a symlink into ~/.local/share/claude/versions/<version>/.

On Windows accounts that don't have SeCreateSymbolicLinkPrivilege (i.e., Developer Mode is not enabled — a common default), the updater appears unable to properly repoint that claude symlink to the new version after an update. It updates claude.exe in place successfully, but the extensionless claude symlink is left pointing at a stale/already-pruned version directory (in my case, versions/2.1.205, several versions behind and no longer present on disk), leaving Bash unable to resolve claude at all while other shells are unaffected.

What Should Happen?

claude should keep working from Git Bash after an auto-update, the same as it does from PowerShell/cmd.

Either:

• The updater should reliably re-point the extension-less claude file/symlink in ~/.local/bin to the current version on every update, even on accounts without symlink-creation privilege (e.g., by falling back to copying/hardlinking the new binary over claude when a real symlink can't be created), or
• The installer should stop relying on a real Windows symlink for Bash compatibility altogether and instead ship a small POSIX shell wrapper script (or just keep claude as a plain copy of the current claude.exe) that's rewritten on every update regardless of symlink privileges.

Error Messages/Logs

No error, warning, or exception was logged anywhere on the system for this failure — checked ~/.claude/daemon.log and other Claude Code data directories under %LOCALAPPDATA% / %APPDATA%. The updater appears to fail silently when it can't create/update the claude symlink.

Supporting evidence from ~/.claude/daemon.log (only place with any version history) showing this has been silently broken across multiple updates, not a single bad update:

[2026-07-09T14:05:54.553Z] [supervisor] ─── daemon start ─── version=2.1.205 pid=16008 origin=transient
[2026-07-09T19:07:03.216Z] [supervisor] ─── daemon start ─── version=2.1.206 pid=32256 origin=transient
[2026-07-17T21:26:17.126Z] [supervisor] ─── daemon start ─── version=2.1.212 pid=26148 origin=transient

~/.local/bin/claude was still pointing at the now-nonexistent versions/2.1.205 when the bug was noticed on 2026-07-19 — meaning the symlink hasn't successfully updated since at least 2.1.205, across the jump through 2.1.206, 2.1.212, 2.1.214, and 2.1.215.

The only user-visible symptom is the shell error itself:
bash: claude: command not found

Steps to Reproduce

1. On a Windows account without Developer Mode enabled (default for most non-admin/non-dev accounts, meaning the account lacks SeCreateSymbolicLinkPrivilege — confirmed via whoami /priv), install Claude Code using the native Windows installer (not npm). It installs to ~/.local/bin/ (claude.exe and an extension-less claude) and ~/.local/share/claude/versions/<version>/.
2. Confirm it works in Git Bash:

$ claude --version
2.1.205 (Claude Code)

1. Let Claude Code auto-update normally over time (no manual action needed — happened silently across several updates: 2.1.205 → 2.1.206 → 2.1.212 → 2.1.214 → 2.1.215).
2. Open a new Git Bash window and run:

$ claude
bash: claude: command not found

1. In the same session, open PowerShell or cmd and run claude — it works fine, reporting the current version (2.1.215).
2. Inspect the Bash-only claude file to confirm the root cause:

$ ls -la ~/.local/bin/claude
lrwxrwxrwx 1 user 197611 51 ... claude -> /c/Users/user/.local/share/claude/versions/2.1.205

1. The symlink still points at 2.1.205, a version directory that no longer exists under ~/.local/share/claude/versions/ (only the current and last couple of versions are retained), while claude.exe in the same directory has been correctly updated to 2.1.215.

Workaround used: manually re-pointing the symlink (ln -sf ~/.local/share/claude/versions/<current> ~/.local/bin/claude) fixes it temporarily, but since the account still lacks symlink privilege, ln -s silently falls back to copying the file instead of creating a real symlink — so the fix doesn't survive the next auto-update either.

The durable workaround I've used for now is to bypass the extension-less claude file entirely by adding a function to ~/.bashrc that calls claude.exe directly (which the updater does reliably keep current):

claude() {
    "$HOME/.local/bin/claude.exe" "$@"
}

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.205

Claude Code Version

2.1.215 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Additional information:

Operating System: Windows 11 Pro, build 10.0.26200

Terminal/Shell: Git Bash (MSYS2), GNU bash 5.2.37(1)-release (x86_64-pc-msys) — bundled with Git for Windows. 
Issue does not reproduce in PowerShell on the same machine.

This seems similar to https://github.com/anthropics/claude-code/issues/69400, https://github.com/anthropics/claude-code/issues/57178, and https://github.com/anthropics/claude-code/issues/45260, and may indicate that the updater's cross-platform symlink management has multiple independent failure modes.