Desktop: file paths outside the working directory no longer open inline ("This file is outside the working directory" → Show in Finder) — regression after update

Confirming this on the additionalDirectories side as well. Files under a permissions.additionalDirectories path (e.g. sibling repos in a multi-repo workspace) hit the exact same "This file is outside the working directory" block in the File Pane, while the agent's Read/Edit/Bash tools operate on those same paths without issue — so it's purely the File Pane's link-resolver, as you noted.

Repro'd on desktop 1.15962.1 and still present on 1.17377.2.

I filed #72423 for the additionalDirectories-specific case before finding this issue; it was closed as COMPLETED but is still reproducible. This one is broader (any path outside the working directory) and still open, so it's the right place to track it. +1

Confirming this is still present on macOS desktop 1.22209.3 — not fixed since the 1.17377.2 build in the report.

My setup makes this a near-constant papercut: I use a "dispatcher" folder as my working directory and have the assistant route documents it creates into sibling project folders. Every one of those docs is therefore outside the working directory, so every link to them hits this gate.

Two additions for repro/triage:

1. "Show in Finder" resolves the wrong path — not just "can't preview." When the assistant emits a working-directory-relative href to a sibling folder (the format its own system prompt asks for — [name](path-relative-to-cwd)), the app resolves it against the working-directory root, so "Show in Finder" opens the working folder itself instead of the target file. Silently pointing at the wrong location is worse than a clear failure.

1. A workaround that works — and a format that breaks it. With the href as the full absolute path, raw spaces and non-ASCII (emoji) characters left unescaped, "Show in Finder" lands correctly. A fully percent-encoded absolute path also works. But angle-bracket-wrapping the URL — [name](</Users/.../file.md>), the CommonMark way to permit spaces — breaks it: the app appears to treat the < and > as literal path characters. My folder names contain both spaces and emoji (Google Drive CloudStorage paths like .../🧡 General Chats/…) and the raw absolute path still resolved, so as long as the path is absolute and unwrapped, the encode/decode problem in #76328 does not bite here.

Net ask, same as the issue: preview outside-working-directory files inline (or allow an allowlist of external dirs). Short term, a "Show in Finder" that resolves the actual href instead of re-rooting it at cwd would remove the wrong-file behavior on its own.

Still present on macOS desktop 1.37937.3 (bundled Claude Code 2.1.246) — so it has survived from the 1.17377.2 build in the report through today, 2026-08-27.

Sharing a workaround that does work, plus a measurement that may point at the cause.

I sat with my assistant and clicked every candidate href form myself for one file in a sibling folder:

| href form | Show in Finder | left-click preview |
|---|---|---|
| raw absolute (/Users/me/…/f.md) | ✅ | ❌ |
| file:///Users/me/…/f.md | ✅ | ❌ |
| fully percent-encoded absolute | ❌ | ❌ |
| relative ../Sibling/f.md | ❌ | ❌ |
| symlink placed inside the working dir | ✅ | ❌ |
| hard link placed inside the working dir | ✅ | ✅ opens |

The last two rows are the interesting pair. A symlink whose own path is inside the working directory is still refused, but a hard link at the same path opens fine — which suggests the File Pane canonicalizes (realpath / resolves symlinks) before the working-directory containment check, rather than checking the path as given. If that is right, honoring the literal path for symlinks would be a small fix and would also cover the additionalDirectories case @street62 describes above, since a workspace symlink is the usual way people wire those up.

Until then, the hard-link route is a usable workaround for anyone hitting this: ln /path/to/outside/file.md ./preview--file.md, link to preview--file.md, delete it after. Because it is the same inode it is not a copy — edits made in the pane land in the real file, so nothing diverges — and it costs no disk. It only works for files on the same volume, and not for directories.

Context for why this bites some of us constantly: I use a dispatcher folder as my working directory and have the assistant route documents into ~40 sibling project folders, so nearly every file it points me at is outside the working directory. Thanks for the work on the app — this one is a small surface with an outsized daily cost.

Confirming on Windows — and I think I found the specific capability flag that decides this.

Environment

• Claude Desktop 1.37937.3 (Windows 11 x64), bundled Claude Code 2.1.246 — same build @geokao reports above
• Working directory: D:\<repo>. Target file: C:\Users\<me>\<docs>\PROGRESS.md — different drive, plainly readable by the agent's own tools in the same session.

The gate has a name: sessionFolderFileAccess

Reading the shipped renderer bundle, the File Pane builds its allowed-roots array like this (resources/ion-dist/assets/v1/c53a94863-*.js):

rn = function(e,t,n){
  return n && t?.sessionFolders
    ? [e, ...t.sessionFolders.map(x => se(x, t.homePath))]
    : [e]
}(workingDir, sessionMeta, Ce())

and Ce() resolves to (shared-1-*.js):

function Rv(){ return "supported" === Sv()?.sessionFolderFileAccess?.status }
function Sv(){ return Uc(e => e.appFeatures) }

So the multi-root path is gated on an appFeatures.sessionFolderFileAccess capability. When that capability is not "supported", the array collapses to a single entry — [workingDir] — and the containment check (XS → ZS in shared-7-*.js) has nothing else to fall through to.

Two consequences worth recording:

1. permissions.additionalDirectories is not consulted here in any form. It is not that the resolver reads it and rejects it — it never enters this array. This gives @street62's observation above a mechanism: the setting extends agent tool access, and the File Pane is looking at an entirely different list.
2. On this machine the capability is evidently not supported for local sessions. My session had C:\Users\<me>\cowork listed as an additional working directory in the session's own system prompt, and a file under it was still refused.

Ruled out as factors, for triage: path normalization already uppercases the drive letter and unifies \ and / (GS), and the link parser slices file:/// without percent-decoding, so raw non-ASCII path segments pass through verbatim. Neither separators nor Unicode are involved.

The error copy splits, and that splits the bug reports

This matters for issue dedup. I did not get the copy in the original report. My panel showed:

This file can't be found — It may have been deleted or moved, or it lives outside the working directory.

No "outside the working directory" title, no explanation that the path is the problem — it reads as a missing file. In the bundle these are two distinct branches (outsideRootUnrenderable vs. the generic fallback), and which one renders depends on a second condition beyond containment; I could not pin down exactly which inputs flip it, but the split is reproducible and it is the same underlying refusal.

#89830 (French UI, filed 2026-08-26) is that second branch: "Ce fichier est introuvable… ou il se trouve en dehors du répertoire de travail." Same gate, different copy, filed as a separate bug. Anyone searching the tracker for the string on their screen will not find this issue.

File cards hit the same gate

Not only chat links. A file delivered as an attachment card and clicked from the transcript is refused identically on Windows. #89830 reports the same on macOS. So there is no in-app surface that reaches an out-of-root file — "Show in Explorer" / "Show in Finder" is the only remaining route, and it does work, which confirms the app has filesystem access and is choosing not to render.

Scale, measured locally

I scanned 1,231 session transcripts on this machine for file:/// links, discarding anything my extraction could not clean unambiguously (percent-encoded paths, :line suffixes, truncated matches, docs examples):

• 663 sessions contained links; 482 of them (73%) linked at least one file outside that session's own working directory
• Counted per session, 2,324 of 5,425 links (43%) are out-of-root
• 2,270 distinct absolute paths overall

Coverage if a user tried to work around this by picking one wide root:

| candidate root | share of linked paths it covers |
|---|---|
| C:\Users\<me> (home) | 71.8% |
| C:\Users\<me>\cowork | 37.2% |
| D:\<projects> | 27.6% |
| C:\Users\<me>\.claude | 15.6% |

No single root reaches 100%, because the paths span two drives and a local session accepts exactly one root. Per the docs, adding further folders to a session is a cloud-session feature (the + button next to the repo pill); local sessions have no equivalent. So there is no user-side configuration that resolves this — which lines up with the capability being off.

Ask

1. Could platform:windows be added next to platform:macos? This is a cross-platform regression and the current label set makes it look narrower than it is.
2. Consider linking #89830 here — it is the same gate reached through the "can't be found" copy, and it will keep collecting independent duplicates as long as that string doesn't lead back to this issue.