[MCP] Support per-session output directory scoping for git-worktree-based agentic coding workflows

Context / workflow pattern

We run @playwright/mcp as a long-lived stdio MCP server inside an agentic coding CLI (Claude Code). Our workflow uses git worktree heavily: a single coding session self-provisions a new worktree mid-session (a sibling directory checked out from the same repo) and does the rest of its work there — including browser-driven QA/evidence capture. Multiple such sessions run concurrently, each in its own worktree.

The problem

--output-dir (and the MCP roots capability) are resolved once, at MCP server process start, against whatever the coding tool's root was at that moment (the primary checkout). When a session later moves its own work into a freshly created worktree, the server's output directory does not follow — it stays bound to the original path for the life of that long-lived server process. Screenshot/trace/evidence writes aimed at the session's own worktree path get denied as "outside allowed roots", and writes that do succeed land in the original (shared) directory, where concurrent worktree sessions collide with each other.

This isn't solved by the existing "isolate concurrent sessions" workarounds, because those target a different axis of the problem:

• Running one MCP server per client (--isolated + distinct --user-data-dir, or a tabId-per-agent scheme as discussed in microsoft/playwright-mcp#893) isolates the browser instance, not the output directory.
• MCP roots is fixed at init and, per the discussion on microsoft/playwright-mcp#1240, is being phased out client-side anyway (SEP-2577). Even where honored, roots reflects the coding tool's session root — which in our case also doesn't change when a worktree is created mid-session; the CLI process's own root stays put, only the working directory used for that sub-task moves.
• The MCP server itself is not restarted per worktree — it's one long-lived server for the whole coding session, config fixed at the start.

What we actually need is one of:

1. A supported way to scope output-dir per-connection or per-call at runtime (e.g., an override accepted alongside a tool call, or the server re-reading roots/cwd against a later negotiation rather than only at init), or
2. Explicit documented guidance for this pattern (many concurrent, worktree-scoped agentic-coding sessions sharing one long-lived MCP server whose config surface is otherwise static).

We'd like to avoid both (a) widening --output-dir to some insecure common-ancestor directory outside the actual project roots, and (b) building/maintaining a custom wrapper MCP server just to re-derive per-worktree paths.

Prior related discussion

• microsoft/playwright-mcp#1240 (closed, redirected from playwright#38416) proposed artifacts-as-resources for remote HTTP deployments; closed as not-planned for the roots-based approach, with a "wrap our MCP into yours" suggestion. That's a different deployment shape (remote/HTTP) from ours (local stdio, git-worktree-based).
• microsoft/playwright-mcp#1295 (closed) asked for per-MCP-session output subdirectories, motivated by mapping video artifacts back to sessions in CI; closed in favor of manually driving the devtools capability's start/stop with explicit paths — doesn't address the local worktree-root-mismatch case.
• microsoft/playwright-mcp#893 and microsoft/playwright-mcp#1594 cover concurrent-session browser-instance/profile contention specifically, not output-dir scoping.

Given the "wrap it yourself" answer on microsoft/playwright-mcp#1240, is there an official recommended pattern for the git-worktree case specifically — or would a small opt-in mechanism (output-dir override per call, or re-reading roots/cwd on a later negotiation) be worth considering?

Happy to provide more detail on the worktree lifecycle if useful.