[Desktop] Relative file links break after Bash `cd`: model uses new cwd, file pane uses session folder
Environment
- Claude Code 2.1.288 to 2.1.291, desktop app (Windows 11), Code tab
- Seen with Opus 5.5, in several sessions (including subagent-heavy ones); other models not tested
Steps to reproduce
- Start a desktop session in a folder, e.g.
D:\work, that has a subfolder.claude\and a fileprojects\demo\PLAN.md. - Ask Claude to run a Bash command that changes into a folder inside the session folder, e.g.
cd .claude && pwd. (Acdoutside the project is reset instead, so it does not trigger this.) - Ask Claude to give you a clickable link to
projects\demo\PLAN.md.
What happens inside, for context: after step 2 the model receives a system note (not visible to the user) readingPrimary working directory: D:\work\.claude (was D:\work).
The system prompt tells it to "Use the path relative to the working directory as the href", so it now writes the link relative to D:\work\.claude: [PLAN.md](../projects/demo/PLAN.md).
Expected
The link opens D:\work\projects\demo\PLAN.md. The base the model is told to write links against and the base the file pane resolves them against should be the same folder.
Possible fixes (any one):
- the file pane resolves relative links against the same current working directory the model is told about; or
- the model is always told the session folder as the base for links, even after a
cd; or - a Bash
cddoes not move the "primary working directory" (the Bash tool description already says "Working directory persists between calls, but prefer absolute paths").
Actual
The file pane resolves the link against the session folder (D:\work), so it points to D:\projects\demo\PLAN.md, and shows: "Couldn't find this file. It may have been deleted, or it lives outside the working directory." The file exists.
Why it matters
Every relative link written after the first cd breaks, and nothing in the UI shows why. It recurs across sessions and looks like a model mistake when it is a mismatch between two parts of the app.
Related, but not the same cause
- #90405: links written relative to the working directory break in git worktree sessions (same mismatch, different trigger).
- #94707: links that point outside the working directory open a dead-end dialog. Here the file is inside the session folder; only the base differs.
- #94796: memory files become unopenable after the working directory changes.
- #92831: the file pane can't reliably show an existing file.
---
Drafted with Claude Code at the user's request.