Show symlinked files and folders in the sidebar

[jaydenfyi]

What problem are you trying to solve?

I keep some notes in symlinked files and folders that I symlink across different git projects. Hubble leaves them out of the sidebar, so I have to open the target directory as another workspace.

What should Hubble do?

Show symlinked files and folders at their linked paths. Follow targets inside and outside the workspace, skip broken links, and prevent directory cycles.

Current workaround

Open the target directory as a separate workspace.

Examples, references, or screenshots

notes/
├── project-notes -> ../project/.notes
└── tickets.md -> ../project/tickets.md

Examples, references, or screenshots

No response

How important is this to you?

3 — Useful improvement

Blocked by

None - can start immediately

Context

I tested this workflow on macOS with a linked directory and a linked Markdown file and they don't show

[github-actions]

Thanks for the detailed report — routing this to needs-discussion, because the requested behavior (following symlink targets outside the workspace) conflicts with an explicit, tested containment boundary rather than being a gap we can just fill in.

What the code does today:

• Symlinked folders whose target resolves inside the open folder are already shown and walked (apps/desktop/electron/workspaceSidebar.ts directoryRealPath), covered by the test "follows symlinked directories within the workspace".
• Symlinks resolving outside the root are dropped on purpose, and the test "does not follow a symlink into another tree" asserts it (apps/desktop/electron/workspaceSidebar.test.ts 118-138) via hasExternalSymlink.
• Symlinked files are excluded in every case, even when the target is inside the workspace: the walk uses lstat, so a link is never isFile(), and fileDelta explicitly returns remove for symlinks (workspaceSidebar.ts:234).

Open decisions before implementation:

• Do we want to relax the "stays inside the open folder" invariant at all? It also lives in apps/desktop/src/lib/workspacePath.ts (assertPathInWorkspace), the granted-scope check in apps/desktop/electron/main.ts (assertGranted), the delta guard at main.ts:1337, and delete/undo. Showing an external link without relaxing those means rows that fail on open, edit, rename, or delete.
• If yes: does it apply to Plain Folders only, or also to synced Workspaces? Following external links means Cloud Sync would upload content from outside the Workspace Folder — that needs an explicit product call.
• Change detection: the sidebar watcher is fs.watch(root, { recursive: true }) (workspaceWatcher.ts:71), which does not traverse symlinks on macOS. External targets would appear but go stale unless we add per-target watches.
• Scoping semantics: .gitignore/.ignore rules are resolved relative to the root chain, so it is undecided whether the link target's own ignore files apply, plus how asset paths (<stem>.assets/) and Embeds resolve for a file whose real path is elsewhere.

A narrower, likely-uncontroversial slice we could split out: show symlinked files whose target resolves inside the open folder, matching existing folder-symlink behavior. If that covers enough of your workflow, say so and we can track it separately from the cross-tree case.

---

Triaged by a Warp Factory agent.