Linked folders

A linked folder attaches an external directory — a code repository, a docs export, a data dump — to a collection as read-only context for Intabula's agent. The agent can read and search there; it can only ever write into your vault.

What the agent can do with a linked folder

• list_linked_files, read_linked_file, search_linked_files — browse, read, and search the folder's files.
• git_log, git_show, git_diff — read a repository's history without ever touching the working tree.

That's the whole surface. There is no write operation for linked folders.

The boundary

Every access is resolved to its real path before a containment check against the linked roots, so a symlink inside a linked folder can't reach outside it. On top of that boundary, a sensitive-file blocklist refuses reads of files like .env variants and paths under secrets/ or .ssh/ — and the same blocklist applies to the Git tools, so a blocked file stays blocked at old revisions too.

Notes that can see your code

The main use: give each repository its own collection with the repo linked. Asking the agent to "write up why we switched the queue implementation — check the actual diff" produces a decision record grounded in the commit, not in memory. Ticket notes carry real file references; architecture notes cite the code they describe. See the engineering decisions use case.

Linked folders vs. external collections

These are different things. A linked folder is read-only context — the agent can look, never write. An external collection is a normal writable collection whose folder happens to live outside the vault (iCloud, an external disk, a shared drive). See Sync, sharing, and iOS.