Root isolation

The effective workspace.roots list comes from environment overrides, project and global TOML, or the selected MCP workspace roots. When no source configures roots, the selected project root is the only boundary.

Resolution rules

• Client-advertised MCP roots are the preferred trusted workspace signal.
• AST_MCP_PROJECT_ROOT selects a project without overriding its policy.
• Relative tool paths resolve from the first effective workspace root.
• Every explicit path-bearing argument is validated.
• Symbolic-link targets are rejected by default. safety.follow_symlinks = true permits only final symlinks whose resolved target remains inside an effective workspace root.
• Configured roots outside the trusted boundary require safety.allow_external_roots = true or the compatible environment override.
• Error messages display the active boundary without exposing unrelated contents.

The same request-scoped configuration applies to file operations and direct ast-bro tools, including path, root, paths, keyed file paths, and destinations.

Multiple workspaces

When a client advertises multiple roots, an absolute request path selects the containing root; pathless and relative requests use the first root. Calls spanning roots fail if their effective safety, formatting, or dependency policies conflict. This prevents one project from silently weakening another project's write policy.

Prefer one repository root per server when possible. Multiple roots remain available for deliberate multi-repository work, but they increase the filesystem state exposed to the connected agent.