claude-in-chrome: `save_to_disk: true` is silently dropped — bytes never persist

Summary

Calling the chrome MCP computer tool with action: screenshot (or zoom) and save_to_disk: true returns a screenshot ID and inline image but does not persist any bytes to disk. The tool description claims "Returns the saved path in the tool result" — no path is returned, and no file is created anywhere on the filesystem.

Environment

• Claude Code: 2.1.138
• macOS: 26.4.1 (Build 25E253)
• Chrome extension: claude-in-chrome (current as of 2026-05-10)
• Native host wrapper: ~/.claude/chrome/chrome-native-host → execs the Claude Code binary with --chrome-native-host

Reproduction

1. In Claude Code, with the chrome MCP connected, call:

\\\json
{
"tool": "mcp__claude-in-chrome__computer",
"input": {
"action": "screenshot",
"tabId": 12345,
"save_to_disk": true
}
}
\\\

1. Tool returns successfully:

\\\
Successfully captured screenshot (1483x812, jpeg) - ID: ss_3670cu9jg
\\\

plus the inline image. No \path\ field in the response text.

1. Search the entire filesystem for any file created since the call:

\\\bash
touch /tmp/marker
# ... call screenshot tool ...
find ~ -type f -newer /tmp/marker 2>/dev/null \
| grep -E '\.(png|jpe?g)$' \
| grep -vE '/(node_modules|\.git/|cache/|Cache/|\.npm)/'
find /tmp /private/tmp /var -type f -newer /tmp/marker 2>/dev/null \
| grep -E '\.(png|jpe?g)$'
\\\

Returns zero image files.

1. Check the chrome MCP log:

\\\bash
tail -20 ~/Library/Caches/claude-cli-nodejs/<cwd-slug>/mcp-logs-claude-in-chrome/*.jsonl
\\\

Records the \Calling MCP tool: computer\ and \completed successfully in 1s\ events, but no save event, no path, no error.

Expected

Either:

• Bytes written to a documented location (e.g. \~/Downloads/\ or \\$TMPDIR/claude-in-chrome/ss_xxxx.png\), AND the path included in the tool result text, OR
• The flag rejected at schema-validation time with a clear "not supported in this Claude Code version" error if the feature has been removed.

Silent acceptance + drop is the worst case — model and user both assume evidence is being persisted, but every screenshot is inline-only and dies with the conversation.

Actual impact

In a multi-hour UAT walkthrough I took ~10 screenshots, all flagged \save_to_disk: true\, and referenced their IDs (\ss_xxxx\) from markdown evidence docs under the assumption they were on disk. Discovered at end-of-session that none had landed; all evidence was inline-only and would dangle the moment the conversation closed.

This silently damages any UAT walkthrough / PR-evidence / regression-record workflow that depends on chrome MCP screenshots.

Suggested fixes (in order of preference)

1. Make \save_to_disk: true\ actually save. Documented destination (e.g. \\$TMPDIR/claude-in-chrome/\ or \~/Downloads/\). Return the path in the tool result text.
2. If the feature is intentionally disabled in this version, reject the flag with a clear error so the model knows to use a different evidence path (e.g. a separate \download_screenshot\ tool).
3. Update the tool description if the flag is genuinely not implemented yet — current wording ("Returns the saved path in the tool result") is misleading and led to silent evidence loss.

Related considerations

• \screencapture\ is not a valid silent fallback because the MCP tab may not be the focused/visible window on the user's display. Documenting that chrome MCP screenshots are inline-only would change how callers structure evidence-gathering workflows.
• The existing \file_upload\ and \gif_creator\ tools suggest disk-IO plumbing exists for related operations — a "download current tab as PNG" tool that explicitly writes to a user-controlled path could be a cleaner fix.

How I confirmed

Marker-based \find\ over entire HOME + temp dirs after a \save_to_disk: true\ call returns zero image files. MCP server log records the call but no save activity.