Per-project setting to keep agents' MCP thread access within their own project

[coygeek]

Summary

Add an opt-in, per-project setting that keeps an agent's T3 MCP thread and project targets inside its own project, for users who want some projects isolated now that MCP targets reach the whole environment by default.

Problem to solve

Since #15219, agents running in any project can list, search, and read threads in every project, and can send to, interrupt, rename, organize, configure, fork, and schedule into threads of other projects whenever the target's modes are within the caller's and the caller has a live run. That is useful for cross-project orchestration, but some users keep client work, private experiments, or sensitive conversations in a project and do not want agents from other projects reading those transcripts or acting on those threads, and do not want that project's own agents reaching out. Read access is not gated by runtime mode: approval-required and plan-mode callers can read other projects' threads, and Claude read-only sandboxes pre-approve the thread list and search tools. Today there is no way to restore a project boundary short of running separate T3 environments. The #13888 resolution noted that "a user-set grant on top of that can be a fresh discussion if it's still wanted."

Proposed behavior

A project gains an "Isolate agent thread access" setting, off by default so current behavior is unchanged. When it is on for a project, T3 MCP tools called by agents running in that project resolve thread and project targets only within that project, and agents in other projects cannot resolve threads or project targets in it. Blocked targets fail with a clear, typed error that says the project is isolated, rather than appearing as missing. The setting covers reads (list, search, read, wait, transfers, configuration), writes (send, interrupt, update, organize, attachments, queue, pending requests, configure, fork, merge-back), and project-targeted creation (launch, schedule) in both directions.

Acceptance criteria

• With the setting off everywhere, all MCP thread and project targeting behaves exactly as today.
• With the setting on for project A, an agent in A that targets a thread or projectId in project B receives the isolation error, and t3_thread_list or t3_thread_search for B returns no data.
• With the setting on for project A, an agent in project B cannot read, list, search, write to, launch into, or schedule into project A.
• An agent in an isolated project can still operate on its own threads and its own delegated children.
• The setting is visible and editable in project settings, alongside the existing per-project agent access settings.

Affected area

MCP target resolution in apps/server/src/mcp/threadAccess.ts (readThread resolves "anywhere in the environment", L164) and apps/server/src/mcp/OrchestratorMcpService.ts, project-targeted tools in apps/server/src/mcp/toolkits/project and the scheduler tools, and project settings in packages/contracts/src/settings.ts, where per-project agent access settings such as enableAgentBrowserAccess (L1135) already exist and are a natural precedent.

Non-goals

• Reverting feat(server): T3 MCP tools take explicit thread and project targets #15219 or changing the default.
• Changing how OAuth-authenticated outside clients (feat(server): outside agents sign in to the T3 MCP server with OAuth #15220) are scoped, beyond honoring an isolated project's boundary if they reach it.
• Per-thread grants or sharing rules.

Alternatives considered

• Restore the old calling-project boundary globally: undoes a deliberate design choice and the cross-project workflows it enables.
• A global environment-wide toggle: coarser than needed; users usually want to isolate specific projects.
• Separate T3 environments per sensitive project: works today but duplicates setup, providers, and settings.

Supporting context

The environment-wide resolution is at threadAccess.ts:164. Related: discussion #13888 (cross-project access, resolved by #15219), discussion #15204 (scoped discovery across projects and environments), discussion #6945 (closed; project isolation described at the time as a stated guarantee). No existing request for an isolation setting was found.