[BUG] vscode out-of-workspace read protection trivially circumvented by symlinks

[nh2]

Even when the

• Include files outside workspace

Read permission setting in "Auto-Approve" is off, the harness in readonly ("Ask") mode will provide file contents via symlinks.

For example, you can create a symlink in the workspace, e.g. myfile pointing to /etc/passwd, and Ask mode will trivially be able to access it.

Suggested solution

That setting should probably be extended by a setting

• Include symlinks in workspace resolving to outside of workspace

so one can control this behaviour.

The harness should then resolve file paths before providing their contents.

[edelauna]

I'm not convinced this is a bug, the workspace is trusted, any symlinks within the workspace should also be trusted, we could maybe consider adding the setting to Disallow symlinks in workspace

[nh2]

I think this is a bit orthogonal to vscode workspace trust. vscode workspace trust is primarily about what stored code in the workspace (e.g. workspace settings, tasks) can do in regards to automatic code execution by vscode.

The harness setting

• Include files outside workspace

is specifically a Read permission limit for the safe readonly harness tooling that Zoo provides. The only thing it has in common with workspace trust is that it uses the same folder (the workspace, which makes sense) but it does not really interact with the "trust" bit.

It is thus pretty surprising to a user that a "Don't include files outside workspace" setting, which essentially is a MCP-style read sandbox, includes files outside the workspace.

---

Since Zoo has full knowledge of the file it opens to provide contents to the model, it is quite against user intuition why it wouldn't perform this obvious check, given that it easily can. It feels like a sandboxing oversight.

(Of course there are some workflows that work based on symlinks, e.g. pointing to read-only files. That's why I think it should be an option.)

[proyectoauraorg]

Opened a fix: isPathOutsideWorkspace() only resolved ./.., not symlinks, so a symlink inside the workspace pointing outside passed the check. The fix resolves the real path (via fs.realpathSync) for both the target and workspace folders before comparing, with a safe fallback for paths that don't exist yet. Added tests with real symlinks.