[BUG] Directory-selection widget disappears when `projects/<slug>/memory` is an NTFS junction (Windows desktop)

Status Open
Reported on v2.1.234
Maintainer reply None cached
Activity 0 comments · opened Aug 19, 2026

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?

When a project slug's auto-memory directory (%USERPROFILE%\.claude\projects\<slug>\memory) is an NTFS junction, new desktop-app sessions in that project folder render without the directory-selection widget. There is no error — the widget just never appears. Everything else in the session works, including auto-memory itself, which loads correctly through the junction.

Verified bidirectionally across four project slugs: junction present → widget gone; junction replaced with a real directory (even byte-identical copied content) → widget back. Two of the slugs were git linked worktrees and one a normal clone — worktree vs. clone made no difference; the junction is the only variable.

Why this matters: junctions on projects/<slug>/memory are how power users share one canonical auto-memory set across git-worktree project slugs (each worktree path gets its own slug, so memory fragments otherwise) — the same usage pattern described as a workaround in #57998. Because the widget vanishes silently, users can end up starting sessions in the wrong folder while trying to work around it.

Possibly related family of Windows filesystem-indirection issues breaking UI surfaces without an error: #78466 (subst drive silently empties the session/resume list), #24964 / #24927 (folder picker rejects junction/symlink paths), #28201 (junction resolution in the working directory).

What Should Happen?

The directory-selection widget should render regardless of whether the project's memory directory is a real directory, a junction, or a symlink — the app already reads memory through the junction without trouble. Failing that, an indirection the app cannot support should produce a visible error rather than silently dropping a UI control.

Error Messages/Logs

None — that is part of the bug. The widget is silently absent; no error is shown in the session UI and the session otherwise behaves normally.

Steps to Reproduce

Environment: Claude desktop app 1.32885.1 (MSIX), claude-code runtime 2.1.234, Windows 11 Enterprise (10.0.26200).

  1. Pick a project folder whose sessions normally show the directory-selection widget, and close all its sessions. Note its slug directory under %USERPROFILE%\.claude\projects\ (the folder path with \ and : replaced by -).
  2. Replace that slug's memory directory with an NTFS junction to any other slug's memory directory (move the contents first if it isn't empty):

``powershell
Remove-Item "$env:USERPROFILE\.claude\projects\<slug>\memory"
New-Item -ItemType Junction

-Path "$env:USERPROFILE\.claude\projects\<slug>\memory"
-Target "$env:USERPROFILE\.claude\projects\<other-slug>\memory"
``

  1. Start a new desktop-app session in the corresponding project folder. → The directory-selection widget does not render. (Auto-memory still loads, via the junction.)
  2. Close the session; replace the junction with a plain directory containing the same files:

``powershell
(Get-Item "$env:USERPROFILE\.claude\projects\<slug>\memory" -Force).Delete()
New-Item -ItemType Directory "$env:USERPROFILE\.claude\projects\<slug>\memory" | Out-Null
Copy-Item "$env:USERPROFILE\.claude\projects\<other-slug>\memory\*"

"$env:USERPROFILE\.claude\projects\<slug>\memory"
```

  1. Start a new session in the same project folder. → The widget renders again. Same content, same paths — only the reparse point changed.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.234

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗