[FEATURE] Files panel (macOS Desktop): follow symlinks — expandable symlinked directories and openable symlinked files (follow-up to #59683)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Filed as a follow-up to #59683, which requested exactly this. That issue was auto-closed as not_planned by the stale bot (label stale) without a fix and is now locked; its closing message asks to open a new issue referencing it — hence this one.

Problem Statement

On the macOS Desktop app, the Files panel does not follow symlinks — and this affects both directories and files.

• A symlink that resolves to a directory shows up as a flat "file with an arrow (↗)" entry: no disclosure triangle, nothing to expand, and its contents cannot be browsed from the sidebar.
• A symlink that resolves to a file shows up the same way — a flat "↗" entry that does not open its target when clicked (and dead-ends when the target is outside the working directory, per #94707 / #94542 / #93101 / #94446).

So the panel effectively ignores symlinks of both kinds. Every other tool follows them transparently — Finder, VS Code, IntelliJ, ls -L, and Claude Code's own Read / Edit / Grep / Bash tools. Only the Files panel doesn't.

My layout composes a sibling git repo into the working tree via a single symlink (a separate "concept/docs" repo surfaced into the code repo, so the docs are browsable next to the code but tracked in their own repo with its own remote):

$ ls -l
lrwxr-xr-x@  proposals -> ../repo-Konzept/docs/

proposals/ resolves to a directory full of Markdown files, but the sidebar shows proposals as a single non-expandable link entry (see screenshot below).

Workaround attempt that also fails: replacing the single directory-symlink with a real directory containing per-file symlinks. The file-symlinks inside then render as the same non-expandable "↗" entries and don't open — which is exactly why this request must cover files as well as directories.

Screenshot

The Files panel renders the folder proposals symlink as a single row with a ↗ arrow and no disclosure triangle — it can neither be expanded (directory case) nor opened (file case):

folder symlink:
<img width="432" height="262" alt="Image" src="https://github.com/user-attachments/assets/7b45e475-cfbe-4730-97f8-ecad06243e49" />

real folder - docs as symlink:
<img width="345" height="92" alt="Image" src="https://github.com/user-attachments/assets/1c83808a-1b28-4068-a001-132b634c05f9" />

Proposed Solution

Make the Files panel follow symlinks, for both kinds:

• Symlinked directories (stat -L reports a directory): render as an expandable folder, identical to a real directory — a working disclosure triangle, clicking lists the resolved target's contents inline, recursive expansion works (symlinked dir → real subfolder → symlinked dir, all browsable).
• Symlinked files (stat -L reports a file): render as a normal, openable file entry that resolves to and opens the target in the editor pane — including targets outside the working directory (ties into #94707 / #94542 / #93101 / #94446).

For both, a small "↗" badge and/or a hover tooltip with the resolved target would signal it's a link.

Edge cases: broken symlinks rendered muted (don't try to expand/open); symlink loops capped at a sensible depth (10–20).

Alternative Solutions

• Reference paths by name in prompts — works (the agent tools follow symlinks), but the sidebar stops being a navigation surface for part of the project.
• Open the sibling repo as its own project window — loses the unified view across repos and forces context-switching.
• Replace symlinks with real directories / copies — defeats the point: the docs live in their own git repo with its own remote, and copying duplicates content and breaks single-source-of-truth.
• git submodules — carries one repo's remote URL into another repo's history, which is exactly what the symlink layout avoids.

Priority

Medium - Would be very helpful

Feature Category

File operations

Use Case Example

1. A code repo surfaces a sibling "concept/docs" repo via proposals -> ../repo-Konzept/docs/.
2. In Finder / VS Code / IntelliJ, proposals/ expands and its Markdown files open normally.
3. In the Claude Desktop Files panel, proposals shows as a single "↗" entry with no disclosure triangle; expanding is impossible.
4. Even a real proposals/ folder holding per-file symlinks doesn't help — the individual file-symlinks show as "↗" entries and won't open.
5. With this feature, proposals/ would expand inline and the files (whether real or symlinked) would open in the editor pane like any other file.

Additional Context

• Follow-up to #59683 — same request (directories); auto-closed not_planned by the stale bot, never implemented, now locked. This issue additionally asks that symlinked files be handled too.
• Related refresh gap: #72726 — the Files sidebar doesn't refresh on external filesystem changes, so converting a symlink on disk isn't reflected until the panel reloads.
• Related open cluster (links resolving outside the working directory dead-end): #94707, #94542, #93101, #94446 — directly relevant to the symlinked-file case.
• Other tools already follow symlinks inline: Finder (alias-arrow badge), VS Code (no badge), IntelliJ (arrow overlay), ls -L.
• Underlying support already exists: Read/Edit/Grep/Bash all follow these symlinks correctly; only the Files panel doesn't — suggesting a fix localized to the file-tree component rather than a deep change.

Environment

• macOS Tahoe 26.6.2 (25G83)
• Claude macOS App: Claude 2.2553.1 (c38127) 2026-09-18T00:41:58.000Z