[BUG] computer tool's save_to_disk silently stops writing files (claude-in-chrome), survives extension/browser/OS/app restart

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment:

Claude Code version: 2.1.222 (also reproduced on 2.1.221 after downgrade)
OS: Windows 11 Home 10.0.26200
Chrome extension: claude-in-chrome (Claude in Chrome)
Summary: The mcp__claude-in-chrome__computer tool's screenshot action with save_to_disk: true stopped persisting files to disk mid-session. The tool still reports success and the image renders correctly inline, but:

No file appears anywhere on disk (searched all claude-chrome-screenshots-* temp dirs and broader filesystem).
The normal "Screenshot saved to: <path>" confirmation text is missing from the tool output entirely (present before the break, absent after).
Last known-good file: a screenshot did save successfully at 2026-08-04 21:40:16 local time. Every screenshot attempt after that point (dozens, across the rest of that session and a new session the next day) rendered visually but wrote nothing to disk.

Steps to reproduce: Not reliably reproducible on demand — it broke spontaneously mid-session during heavy use of the computer tool against a flaky third-party site (many tab reconnects due to that site timing out). Once broken, it stayed broken across:

Reconnecting to the same Chrome instance (multiple times)
Switching to a second, previously-untried connected Chrome browser instance
A full Chrome quit/relaunch
A full Windows restart
A full Claude Code app quit/relaunch (same version, 2.1.222)
Downgrading Claude Code to the previous version, 2.1.221, then restarting
None of the above restored file-saving. The bug persisted identically across all of them.

What still works fine throughout: page navigation, clicking, javascript_tool DOM inspection/execution, and the screenshot/zoom actions' inline visual rendering — only the disk-persistence side of save_to_disk is affected.

Ruled out:

Disk space (103GB free)
Folder permissions (normal 0755, owned by the user, verified via PowerShell and Bash)
Chrome enterprise policy (chrome://policy showed no download/extension restrictions)
Chrome's download history (chrome://downloads) shows zero entries at all for these screenshot writes — not even blocked/cancelled ones — suggesting the save path doesn't go through Chrome's normal Downloads API, and the failure is likely in a native-messaging bridge or backend component behind the claude-in-chrome MCP tool rather than in Chrome itself.
Suspicion: given it survived every local restart including the Claude Code app itself, the failing component may be server-side / in a persistent piece of the claude-in-chrome bridge infrastructure rather than purely local browser/OS state.

Conclusive isolating test: while troubleshooting, we confirmed the Claude in Chrome side panel feature (a separate built-in Chrome extension UI, distinct from the Claude Code computer tool) could take a screenshot and successfully save/download it — verified directly: a genuine valid JPEG (download.jfif, 108KB) appeared in the Downloads folder with a fresh timestamp matching the side-panel action, at the exact same time the Claude Code computer tool's save_to_disk continued to write nothing. This proves, on the same machine/browser/extension install, in the same moment:

File-writing to disk from Chrome works fine (rules out Windows/permissions/disk space).
The extension's screenshot-capture + file-save pipeline works fine in general (rules out the extension being broadly broken).
The failure is specific to the code path invoked by Claude Code's computer tool (mcp__claude-in-chrome__computer, action screenshot/zoom with save_to_disk: true) — not a general extension or browser capability issue.
Version tested: confirmed present on both 2.1.222 and 2.1.221 (downgraded via npm install -g @anthropic-ai/claude-code@2.1.221, restarted, retested — bug persisted identically). Re-updated back to 2.1.222 afterward. Not related to the version bump.

Likely root cause, narrowed down further: attempted an alternative workaround — using javascript_tool to fetch an image's bytes directly (fetch() + blob) and trigger a real file download via a <a download> element, clicked with a genuine trusted click dispatched through the computer tool (not a synthetic element.click()). Result: the click registers correctly on the page (visually confirmed, no navigation/error), but no file is ever written and no browser download UI appears — the download silently no-ops.

This matches a well-known Chrome/DevTools-Protocol (CDP) behavior: Chrome disables file downloads by default for any tab that is being driven through CDP (which is how browser-automation tooling like this works) unless something explicitly issues Page.setDownloadBehavior (or the equivalent modern API) to allow it and specify a target directory. Regular webpage-triggered downloads (<a download>, window.open to a file, etc.) are silently blocked under this default, while an extension's own privileged chrome.downloads.download() API call (unaffected by the CDP restriction) still works fine — which is exactly why the separate Claude-in-Chrome side panel feature can still save a screenshot successfully (it likely uses that privileged API directly) while the computer tool's save_to_disk (which may go through a CDP-mediated path, or a native-messaging bridge whose own permission got reset/desynced) cannot.

Hypothesis for the fix: whatever internal mechanism backs save_to_disk for the computer/zoom actions should ensure Page.setDownloadBehavior (or the CDP session's equivalent modern download-allow call) is (re-)issued for the tab's CDP session before attempting to persist a screenshot — it's possible this call is only made once at initial connection and doesn't survive/reapply across the kind of reconnects (tab group changes, browser switches) that happened repeatedly during our session, explaining why it broke once and never recovered despite every client-side restart we tried.

Impact: Any workflow relying on save_to_disk (e.g. cropping/processing screenshots with external tools) is blocked until this resolves, with no known client-side fix — including no available browser-triggered-download workaround, since that path is blocked by the same underlying CDP restriction.

What Should Happen?

When save_to_disk: true is passed to the computer tool's screenshot or zoom action, the captured image should be written to a file in the local temp directory (e.g. claude-chrome-screenshots-*), and the tool's response text should include a "Screenshot saved to: <path>" confirmation line with the actual file path — every time, regardless of how long the session has been running or how many times the browser tab/connection has been reconnected.

Error Messages/Logs

Steps to Reproduce

Use the computer tool's screenshot action with save_to_disk: true repeatedly over a long session (mine involved heavy back-and-forth with a slow, flaky third-party website causing many tab timeouts/reconnects).
At some point mid-session, it silently stops working: the tool still reports "Successfully captured screenshot..." and the image still renders inline, but the "Screenshot saved to: <path>" line disappears from the output, and no new file appears in the claude-chrome-screenshots-* temp folder.
Once broken, it stays broken — confirmed still broken after: reconnecting the extension, switching to a second connected Chrome browser instance, fully quitting/relaunching Chrome, restarting Windows entirely, and fully quitting/relaunching Claude Code itself.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.222 (also reproduced identically on 2.1.221 after downgrading to test whether the version update was the cause — it wasn't).

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_