[FEATURE] Files panel (macOS Desktop): render symlinked directories as expandable folders

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)

Problem Statement

I work in a project that deliberately composes multiple sibling git repos into one working tree using symlinks (not git submodules — that pattern doesn't fit when the parent repo pushes to multiple per-org downstream remotes). The layout looks like:

docs/cool                       →  .local/composefiles/cool/docs
docs/sweet                     →  .local/composefiles/sweet/docs
src/main/groovy/config/cool     →  .local/composefiles/cool/config/cool
src/main/groovy/config/sweet   →  .local/composefiles/sweet/config/sweet

Every tool I use sees these as folders — Finder, IntelliJ, VS Code, ls, find, and Claude's own Read / Edit / Grep / Bash tools all follow them transparently.

The Files panel in the Claude Desktop app (macOS) does not. Symlinked directories show up as flat link entries: no disclosure triangle, or one that does nothing when clicked. I can't browse into them from the sidebar.

The practical impact: the sidebar gives me an incomplete picture of my project. I have to remember which folders are "really" populated and reference them by path in prompts, rather than navigating visually like in every other tool. It makes the project feel half-broken in the UI even though the underlying filesystem is fine and the tools work correctly.

Proposed Solution

When a Files-panel entry is a symlink that resolves to a directory (stat -L reports a directory), render it as an expandable folder, identical to a real directory:

• Show a working disclosure triangle.
• Clicking it lists the symlink target's contents inline, same as any other folder.
• Recursive expansion works (i.e. a symlinked dir containing a real subfolder containing a symlinked dir — all browsable).

A subtle visual indicator so I can still tell it's a symlink would be nice but not essential — options that other tools use: a small "↗" overlay on the folder icon, an italic name, or a chevron-arrow badge. Hover tooltip showing the resolved target would be lovely.

For the edge cases:

• Symlinks to files — keep current behavior.
• Broken symlinks — render muted/strikethrough, don't try to expand.
• Symlink loops — depth cap (most file trees use 10–20) and don't infinitely expand.

Alternative Solutions

Things I've tried or considered:

1. Reference paths by name in prompts. Works — Claude's Read/Edit/Grep/Bash tools all follow the symlinks. This is what I do now. The cost is the sidebar is no longer a useful navigation surface for half my project.
2. Open the real .local/composefiles/<org>/ paths as separate project windows. Loses the unified view across orgs, forces context-switching between windows, breaks the seed DSL that expects everything in one tree.
3. Replace symlinks with real directories. Defeats the architectural reason for the layout — each composefiles/<org>/ is its own git repo with its own remote, and collapsing them into one tracked tree creates the multi-remote submodule problem the symlink pattern was designed to avoid.
4. Use git submodules instead. Same problem as #3 — .gitmodules carries one org's repo URL into another org's history, which is exactly what this project's design forbids.

None of these are real fixes. They're all workarounds for a UI rendering choice.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

A typical session in this project:

1. I open the Claude Desktop app on a jenkins_seeds checkout. The repo contains generic seed-DSL code plus symlinks that surface each org's composefiles repo into the working tree.
2. The Files panel shows docs/, src/, etc. I expand docs/ and see two entries: cool and sweet. Both are symlinks.
3. I want to read docs/cool/PRESENTATION.md — a real file at .local/composefiles/cool/docs/PRESENTATION.md surfaced via the docs/cool symlink.
4. I click the disclosure triangle on docs/cool. Nothing happens — or the entry doesn't have one at all.
5. To actually browse the contents I have to either: (a) ask Claude to ls docs/cool in chat, or (b) navigate down through .local/composefiles/cool/docs/ (the real path), which works but breaks the project's intended top-level structure.

What I want instead:

1. Click disclosure triangle on docs/cool.
2. Sidebar expands to show PRESENTATION.md, README.md, completed_plans/, etc. — all browsable, all openable in the editor pane.
3. A small "↗" badge on the docs/cool folder icon tells me it's a symlink so I'm not surprised when I notice it's not tracked by the parent repo's git.

This is exactly how IntelliJ, VS Code, and Finder all already behave for the same on-disk layout.

Additional Context

Underlying support already exists. Claude's Read, Edit, Grep, and Bash tools all transparently follow symlinks — the engine resolves them correctly. The Files panel is the only surface that doesn't. This suggests the fix is localized to the file-tree component, not a deep architectural change.

How other tools handle this:

• macOS Finder — symlinked directories expand inline; alias arrow badge.
• VS Code — symlinked directories expand inline; no badge by default.
• IntelliJ / JetBrains — symlinked directories expand inline; arrow overlay on the icon.
• ls -F — appends @ to symlinks, / to directories; ls -L follows them.

Claude 1.7196.0 (2dbd78) 2026-05-12T05:34:40.000Z