A Workspace Root Needs an Explicit Task-Scope Record

When a user selects a project for an agent, the product often turns that moment into an invisible promise: this is the workspace.

That promise is useful, but incomplete.

Protocol status, September 2026: The official 2026-07-28 release deprecated MCP Roots. New implementations should pass directories or files through tool parameters, resource URIs, or server configuration. Existing implementations can continue using Roots during the deprecation window, but Roots are informational relevance guidance rather than protocol-enforced access control.

A workspace root can tell a client and a server where a user expects work to be relevant. It does not, by itself, decide which files matter to the current task, whether the root is still available, whether an operation is read-only or consequential, or whether a cross-project reference should broaden the task. Those are application decisions that can change while an agent is running.

Treat a root as one relevance signal, then establish an application-enforced task-scope boundary.

A Root Is One Input to a Larger Policy

The current MCP Roots specification describes a way for clients to tell servers which directories and files they consider relevant. It explicitly says Roots are informational guidance rather than access control. It also marks the feature deprecated and directs new implementations toward tool parameters, resource URIs, or server configuration.

In the 2026-07-28 stateless protocol, a server obtains roots during a supported request through the Multi Round-Trip Requests pattern. The Roots page still calls on clients to expose only appropriately permitted roots, validate URIs, enforce access controls, and monitor accessibility, while servers should handle unavailable roots and validate paths. Those responsibilities live in the application and server; the existence of a root does not enforce them.

That is valuable protocol support. The application still has to answer several questions the root alone cannot resolve:

• Question: What is the task trying to accomplish? — Why the root alone is insufficient: A whole project can be in scope while only one behavior or artifact is relevant.
• Question: What may the agent do inside it? — Why the root alone is insufficient: Context inclusion, read access, drafting, testing, and applying a change are different operations.
• Question: Which data should remain out of active context? — Why the root alone is insufficient: A workspace can contain unrelated material that does not belong in a model turn.
• Question: Is the root still the current workspace? — Why the root alone is insufficient: A root can become unavailable, be replaced, or be supplemented by another root while work is active.
• Question: May the agent cross into another root? — Why the root alone is insufficient: A related repository, generated artifact, or shared directory may require an explicit task decision.

The MCP Resources specification reinforces the distinction: resources are application-driven context, and the host decides how to include them. A directory being visible does not mean every file should be injected into an agent’s context.

Similarly, the MCP Tools specification treats tools as executable capabilities with validation, confirmation, timeout, access-control, and audit considerations. A root can guide where a tool might operate; it does not turn every operation under that root into an approved action.

The Workspace Scope Record

The Workspace Scope Record is a proposed companion to a root selection. It is not a filesystem access-control system, a record of private file paths, or a replacement for service authorization. It is the task-level account of what a workspace reference means right now.

• Record element: Root reference and display label — Question it answers: Which user-selected workspace boundary is relevant? — Why it matters: Gives people a comprehensible identity without copying literal paths into broad logs or prompts.
• Record element: Task purpose — Question it answers: What work is this root being used for? — Why it matters: Prevents “the repository is available” from becoming “anything in it is relevant.”
• Record element: Access posture — Question it answers: Is the task contextual, read-only, draft-producing, test-running, or awaiting a separately authorized effect? — Why it matters: Separates visibility from the next action.
• Record element: Included and excluded areas — Question it answers: What logical areas or data classes are relevant or deliberately out of scope? — Why it matters: Reduces unnecessary context and protects unrelated material.
• Record element: Observed-at and availability — Question it answers: When was this scope last checked, and is the root still usable? — Why it matters: Keeps a stale selection from being presented as live state.
• Record element: Cross-root relationship — Question it answers: Is another root a dependency, comparison source, handoff target, or explicitly out of scope? — Why it matters: Makes multi-repository work intentional instead of accidental.
• Record element: Change and re-entry rule — Question it answers: Which root or task changes require the agent to pause, refresh, or ask? — Why it matters: Lets a resumed run react truthfully to a changed workspace.
• Record element: Evidence and retention posture — Question it answers: What minimal references support the record, and what should not be retained? — Why it matters: Preserves reviewability without storing raw path lists, private content, or hidden context.

The record’s central rule is modest: an agent can use the current workspace scope to orient its work, but it must not infer a broader objective or authority from the fact that a root exists.

Separate relevance, access, and effect

Workspace designs often collapse three different meanings into one folder picker.

• Layer: Relevance — Question: Which workspace is related to this task? — Example safe interpretation: The agent may summarize the project structure needed to understand the stated request.
• Layer: Access — Question: Which material can the application expose for the task? — Example safe interpretation: The host can provide only task-relevant files or resources according to its policy.
• Layer: Effect — Question: Which change, if any, may be proposed or applied? — Example safe interpretation: A code change needs authority that the root itself does not grant; existing explicit authorization may already satisfy that requirement.

Keeping these layers separate makes an agent more precise rather than less capable. It can say, “This workspace is related, but this file is outside the task’s stated scope,” or “I can inspect the relevant area, but the proposed change requires its own review boundary.”

It also keeps public artifacts safer. A review package usually needs a project label, a task description, and evidence references—not an exhaustive list of local paths or a copy of unrelated files.

Workspace scope can drift while work continues

Roots are not permanently true just because they were selected at the start. MCP 2026-07-28 is stateless, and a Roots response is obtained within the processing of a particular request. The current Roots specification still asks clients to monitor root changes and accessibility and asks servers to handle roots that become unavailable. Those facts support an application-level design inference: persistent workspace state is application-owned, and a root change should invalidate assumptions that depend on the old scope.

Examples of scope drift include:

• a user replaces the selected project with a different one;
• a task is handed from a single repository to a multi-repository change;
• a required artifact moves outside the original logical work area;
• the workspace is no longer accessible when a long-running task resumes; or
• a previously relevant file is replaced by a newer source of truth.

The correct response is not always to stop. A read-only research task may be able to refresh its view and continue. A proposed cross-workspace effect may need a new decision. A task whose root disappears may need to hold with a clear explanation rather than fabricate a current result.

The Workspace Scope Record gives the runtime a place to make that disposition explicit.

Make Cross-Root Work Explicit

Coding work often spans a library, an application, a deployment configuration, generated artifacts, or documentation. Those may live in different roots. The technical relationship between them does not automatically create a task relationship.

Before an agent crosses a root boundary, it should classify the relationship:

• Reference: inspect a related source to understand an interface, without changing either workspace.
• Dependency: a task in one workspace cannot be evaluated without a bounded check in another.
• Handoff target: an artifact is prepared for a separate workflow, not applied silently.
• Out of scope: the relationship exists, but the current task does not authorize work there.

This distinction is especially useful for review. A reviewer can see that a task considered an adjacent workspace without assuming an unrequested change happened there.

Keep Root State Sparse and Useful

The root record should be deliberately sparse. An agent does not need a complete file inventory to explain why it worked in a project. It normally needs:

• a user-safe workspace label or stable reference;
• the task purpose and current access posture;
• a small description of relevant logical areas;
• a last-observed state or revalidation point; and
• a record of any material cross-root boundary.

Avoid storing raw paths, personal directory names, secret files, broad file trees, or private code excerpts in a durable coordination record. If deeper verification is needed, retain a protected reference that a properly authorized reviewer can access rather than duplicating the material across logs and prompts.

This is not a claim that path information is always sensitive. It is a data-minimization habit: retain the smallest workspace context that helps the next legitimate decision.

A practical adoption path

1. Identify one workspace-aware workflow that can run long enough for its environment to change.
2. Separate the user-visible root selection from the task’s concrete purpose and access posture.
3. Record only logical scope and safe references in the task state; keep raw paths and content outside broad coordination records.
4. Define which events make the workspace view stale: a root change, unavailability, a new dependency, or a material task correction.
5. Classify any cross-root operation before it is included in a plan, handoff, or change proposal.
6. Require a current scope record before a task presents a workspace-dependent claim as verified.
7. Review a completed task and a resumed task to see whether the record explains what the agent was allowed to treat as relevant.

The goal is not to make workspace selection burdensome. It is to prevent a user’s sensible project choice from quietly becoming unlimited context, unlimited task scope, or unlimited authority.

A Virillio Code Editorial Perspective

Virillio Code Editorial presents the Workspace Scope Record as a product-neutral educational framework: a workspace reference remains useful only when it stays connected to a task purpose, current access posture, and revalidation boundary. It does not describe a shipped or planned Virillio Code capability.

Sources and further reading

• Roots — Model Context Protocol — The current specification marks Roots deprecated, defines them as informational relevance guidance rather than access control, uses request-scoped retrieval, and retains permission, path-validation, accessibility, and unavailability guidance.
• Multi Round-Trip Requests — Model Context Protocol — The current stateless protocol retrieves roots through an InputRequiredResult and a retry carrying the matching input response.
• Resources — Model Context Protocol — Resources are application-driven context, with the host determining inclusion and change-handling behavior.
• Tools — Model Context Protocol — Tools are executable capabilities with confirmation, validation, access-control, timeout, and audit considerations distinct from contextual resources.
• The 2026-07-28 Specification — Model Context Protocol — The official release article documents the stateless revision, Multi Round-Trip Requests, and the deprecation of Roots.

Editorial disclosure

This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.