chrome-devtools-mcp filePath writes rejected for every path: "not within any configured workspace roots"

[roboweaver]

Summary

Both bundled chrome-devtools-mcp server configs (chrome-devtools headless and chrome-devtools-visible) reject every filePath value passed to take_screenshot / evaluate_script with:

Access denied: path <X> (canonical: <Y>) is not within any of the configured workspace roots.

This makes it impossible to persist a screenshot to disk via these tools, in any session, regardless of path.

Environment

• Copilot CLI version: 1.0.80 (COPILOT_CLI_BINARY_VERSION)
• Session type: worktree-backed project session (workspace_type: worktree)
• Project: repo-backed project, worktree path /Users/robw/Projects/copilot-worktrees/grimoire/robw-adobe-urban-system, registered main_repo_path = /Users/robw/Projects/grimoire
• macOS (Darwin), two-display setup

mcp-config.json entries (relevant)

"chrome-devtools": {
  "tools": ["*"], "type": "local", "command": "npx",
  "args": ["-y", "chrome-devtools-mcp@latest", "--headless", "--isolated"], "env": {}
},
"chrome-devtools-visible": {
  "tools": ["*"], "type": "local", "command": "npx",
  "args": ["-y", "chrome-devtools-mcp@latest"], "env": {}
}

No --root / workspace-root flag is passed to chrome-devtools-mcp in either config, so whatever restricts filePath is not coming from a documented CLI arg to the MCP server itself — it looks like it must be enforced via the MCP roots capability that the Copilot app (as MCP client) advertises to the server, and that roots list appears to be empty or otherwise not matching any real directory for this session.

Steps to reproduce

1. Start a worktree-backed project session for any repo.
2. Use chrome-devtools-visible-navigate_page to load any URL.
3. Call chrome-devtools-visible-take_screenshot(filePath: "<any path>").
4. Observe rejection with "not within any of the configured workspace roots", regardless of the path chosen.

Paths tested (all rejected identically)

• The session's own worktree path (e.g. /Users/robw/Projects/copilot-worktrees/grimoire/robw-adobe-urban-system/docs/images/...png)
• /tmp/*.png
• The user's home directory root
• The session workspace/state directory
• The project's registered main_repo_path (/Users/robw/Projects/grimoire/.mcp-filetest-DELETE-ME.png) — tested specifically to check whether switching from a worktree session to the main-checkout session would fix it. It did not; rejected identically.
• Both the headless (chrome-devtools) and visible (chrome-devtools-visible) tool variants show the exact same behavior.

Screenshots without a filePath argument work fine (return inline image data) — only disk persistence via filePath is broken.

Investigation performed (no fix found)

Searched for any user-editable configuration governing this and found none:

• ~/.copilot/mcp-config.json (current + all .bak.* backups) — no root/workspace/sandbox/allowed keys found anywhere, and no roots-related args passed to the chrome-devtools-mcp process.
• ~/.copilot/settings.json, ~/.copilot/config.json — no relevant keys.
• macOS defaults read com.github.githubapp — no relevant keys (only an unrelated NSOSPLastRootDirectory save-panel bookmark).
• Shell environment inherited by the session — no *ROOT*/*WORKSPACE* env vars set.

This suggests the restriction is enforced dynamically, in-process, by the running Copilot app itself (most likely via the MCP roots capability sent to the chrome-devtools-mcp server at connection time), and is not something a user can fix via any on-disk config, environment variable, or by choosing a different project/session type.

Impact

Any workflow that needs chrome-devtools* MCP tools to persist a screenshot or other file to disk is completely blocked — there is no working filePath value in any observed configuration. This blocked a documentation task (capturing side-by-side product screenshots for a docs page) with no viable workaround inside the tool.

Expected behavior

take_screenshot/evaluate_script filePath writes should succeed for at least the session's own workspace/worktree directory (and ideally any path the user's shell already has write access to), matching what other filesystem-writing tools in the same session are permitted to do.