[BUG] `claude --update` downloads new version but fails to promote binary from `versions/` to `.local/bin/` on Windows with NTFS junction

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?

claude --update downloads the new binary to %USERPROFILE%\.local\share\claude\versions\ and reports a successful update, but never promotes it to %USERPROFILE%\.local\bin\claude.exe. claude --version continues to report the old version after the update completes.

The %USERPROFILE%\.local directory is an NTFS junction pointing to a directory on a different volume (D:\UserData\michael\.local). The promotion step (copy or rename from versions\ to bin\) silently fails without any error output. The binary in bin\ is untouched: same timestamp, same size, same version.

Reinstalling via irm https://claude.ai/install.ps1 | iex also does not replace the binary in bin\.

What Should Happen?

After claude --update reports success, %USERPROFILE%\.local\bin\claude.exe should be replaced with the newly downloaded version from %USERPROFILE%\.local\share\claude\versions\. If the file replacement fails (e.g., due to cross-volume junction resolution), the updater should report an error rather than reporting success.

Error Messages/Logs

No error messages are produced.  The updater reports success despite the binary not being updated:


⛯ D:\brain$ claude --version
2.1.86 (Claude Code)

⛯ D:\brain$ claude --update
Current version: 2.1.86
Checking for updates to latest version...
Successfully updated from 2.1.86 to version 2.1.87

⛯ D:\brain$ claude --version
2.1.86 (Claude Code)


The new binary is downloaded but not promoted:


⛯ D:\brain$ Get-ChildItem "$env:USERPROFILE\.local\share\claude\versions"

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           3/27/2026  5:50 PM      238222496 2.1.86
-a---           3/30/2026  9:42 AM      238222496 2.1.87


The binary in `bin\` is unchanged after the update:


⛯ D:\brain$ Get-Item "$env:USERPROFILE\.local\bin\claude.exe" | Select-Object LastWriteTime, Length

LastWriteTime           Length
-------------           ------
3/27/2026 5:50:42 PM    238222496    # Unchanged — still the 2.1.86 binary


No log directory exists at `%USERPROFILE%\.claude\logs`.

Steps to Reproduce

1. Install Claude Code via native installer (irm https://claude.ai/install.ps1 | iex) on Windows 11.
2. Configure %USERPROFILE%\.local as an NTFS junction pointing to a directory on a different volume (e.g., D:\UserData\michael\.local).
3. Confirm claude --version reports the current version (e.g., 2.1.86).
4. Run claude --update.
5. Observe the updater reports: Successfully updated from 2.1.86 to version 2.1.87.
6. Run claude --version — still reports 2.1.86.
7. Inspect %USERPROFILE%\.local\share\claude\versions\ — both 2.1.86 and 2.1.87 binaries are present.
8. Inspect %USERPROFILE%\.local\bin\claude.exe — timestamp and size unchanged from before the update.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.87 (in versions/), 2.1.86 (in bin/ — the actually executed binary)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment details:

• OS: Windows 11
• Shell: PowerShell 7.6.0
• Auth: Claude Max (OAuth)
• VS Code extension: Also installed (anthropic.claude-code, independently manages its own bundled binaries per version)

NTFS junction configuration:

C:\Users\michael\.local  →  Junction  →  D:\UserData\michael\.local

%USERPROFILE% resolves to C:\Users\michael. Only C:\Users\michael\.local\bin is in $env:PATH. This is a common enterprise and power-user configuration on Windows for redirecting user data to a separate volume.

Workaround:
Manually promote the downloaded binary:

Copy-Item "$env:USERPROFILE\.local\share\claude\versions\2.1.87" "$env:USERPROFILE\.local\bin\claude.exe" -Force

Likely root cause:
The updater may be using a filesystem operation (e.g., fs.rename / MoveFile) that does not work across volume boundaries. Since the junction maps from C: to D:, the versions\ directory and the bin\ directory resolve to paths on D:, but the updater may be resolving one path through the junction and the other directly, resulting in a cross-volume rename that silently fails. Using fs.copyFile + fs.unlink (or the equivalent) instead of fs.rename would handle this correctly.