[Bug]: Not following symlinks to iCloud~Drive, can't read files/see diffs

[dpkass]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Symlink any iCloud~Drive folder to a project
2. Try reading any of it's contents

Expected behavior

Can read files

Actual behavior

Can't read files and get this error message:

Impact

Major degradation or frequent failure

Version or commit

Latest stable

Environment

macOS 15.5

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Need to open files in Obsidian (yes I use obsidian, judge me all you want)

[dpkass]

Codex investigation notes: this does not appear to be an exact duplicate, but several closed issues are relevant:

• Workspace writes can escape the project root through symlinks #4223 documents the workspace containment boundary. readFile already rejects symlinks whose canonical target is outside the project root; that issue concerned bringing writes under the same restriction.
• [Feature]: Add-project path autocomplete omits symlinked directories and macOS Finder aliases #2135 concerns selecting symlinked directories in the add-project picker. Selecting the symlink itself as a project root is supported behavior, but it is different from following a symlink located inside another project.
• [Bug]: Fail to open a file from the diff because the project is inside a git repository subfolder #6166 produced the same generic “Failed to read workspace file” message for diff files, but its cause was incorrect repository-relative path translation for a project nested inside a Git repository. fix(web): open diff files from nested projects #6174 fixed that case.
• Allow browser preview for absolute file links outside project root #5125 is useful prior art for authorizing an explicitly selected file outside the project root with a short-lived exact-file capability.

The distinct behavior in this report is that the workspace index follows an external directory symlink and lists its contents, while projects.readFile resolves the same path and rejects it as resolved_path_outside_root. The behavior is not specific to iCloud; an ordinary directory symlink that leaves the project root reaches the same containment check.

A safe resolution probably needs either explicit authorization for external symlink targets or consistent filtering and messaging in the workspace index. Simply removing the canonical containment check would allow a project symlink to expose arbitrary files readable by the server process.

[fMads]

I have the same issue - one of the sub-directories in my project is symlinked from a Dropbox directory.
I cannot open and view those files in the file view