Browser pane screenshot has no filePath — can't produce a file for gh --attach or any file consumer

Status Open
Reported on v2.1.270
Maintainer reply None cached
Activity 0 comments · opened Sep 15, 2026

What's missing

mcp__Claude_Browser__computer with action: "screenshot" returns the image into the conversation. It has no filePath parameter, so there is no way to get the bytes onto disk.

By comparison, mcp__chrome-devtools__take_screenshot does take filePath:

filePath — The absolute path, or a path relative to the current working directory, to save the screenshot to instead of attaching it to the response.

Why it matters

Anything that consumes a screenshot as a file can't use the pane. The case I hit repeatedly is attaching screenshots to a GitHub PR, which is a plain CLI flow:

gh pr edit 1234 --attach './screen.png#Alt text'

--attach takes a path. So a task that is otherwise entirely inside the pane — start the dev server, drive the app to the right state, verify it — has to switch to chrome-devtools for the capture step alone.

That switch is not free:

  • chrome-devtools launches an isolated browser with a throwaway profile, so it starts signed out. Reaching an authenticated screen means re-doing the login in the second browser before every capture round.
  • It's a second browser window the user isn't looking at, which defeats the point of the pane being the surface they can already see.
  • The two browsers don't share session state, so there's no way to split the work — drive in the pane, capture in Chrome — and have the capture land on the right screen.

Repro

  1. mcp__Claude_Browser__preview_start or navigate to any page.
  2. mcp__Claude_Browser__computer with {action: "screenshot"}.
  3. The image comes back in the tool result. There is no parameter that writes it to disk, and nothing downstream (gh --attach, an image-diff tool, a file the user opens later) can consume it.

Ask

Add an optional filePath to the pane's screenshot action, matching chrome-devtools' semantics — write the file and skip attaching the image to the response. Same for browser_batch entries, so a multi-step capture run stays one round trip.

Context

Real usage, not hypothetical: this came up while attaching four screenshots to a design PR. The whole session ran in the pane except the capture, which needed Chrome plus a separate login. Prior art in the repo: #10646 (closed) asked for native browser integration generally; this is about the file-output gap in what shipped.

Claude Code 2.1.270, macOS 27.0, desktop app.

View original on GitHub ↗