[Desktop] Relative file links break after Bash `cd`: model uses new cwd, file pane uses session folder

Status Open
Reported on v2.1.288
Maintainer reply None cached
Activity 0 comments · opened Oct 6, 2026

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

  1. Start a desktop session in a folder, e.g. D:\work, that has a subfolder .claude\ and a file projects\demo\PLAN.md.
  2. Ask Claude to run a Bash command that changes into a folder inside the session folder, e.g. cd .claude && pwd. (A cd outside the project is reset instead, so it does not trigger this.)
  3. 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) reading
Primary 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 cd does 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.

View original on GitHub ↗