[BUG] Desktop (Windows): Browser pane raises a native Save As dialog on every download, so Claude cannot save a file from a page
What happens
In the Claude Desktop app's Code tab, any download started inside the built-in Browser pane opens a native Windows Save As dialog owned by claude.exe. Claude's browser tools cannot see or act on that dialog, so the turn carries on as if the download happened, the file never lands, and the dialog sits on screen until the user notices it. A job that downloads several files raises one dialog per file.
There is no setting for it: nothing in Settings, and the documented pane controls (site approvals, Keep cookies, clear data, turn the Browser off) do not cover downloads. The desktop and built-in browser docs do not mention downloads at all.
Steps to reproduce
- Windows 11, Claude Desktop 2.16120.0, Code tab, a local session.
- Open any https page in the Browser pane (for example https://example.com).
- Have Claude run this through the pane's JavaScript tool, or click any link served with
Content-Disposition: attachment:
const a = document.createElement('a');
a.href = URL.createObjectURL(new Blob(['test'], { type: 'text/plain' }));
a.download = 'pane-save-test.txt';
document.body.appendChild(a);
a.click();
Actual
- A Windows common file dialog (window class
#32770, owner processclaude, title is the blob URL) opens. - Nothing is written to Downloads.
- The tool call returns normally, so Claude has no signal that a dialog is waiting.
- Closing the dialog cancels the download.
Expected
One of:
- the pane saves to the user's Downloads folder (or the session folder) with no dialog, as Chrome does by default, and reports the saved path back to the tool call; or
- a setting for the pane's download behaviour and folder; or
- at minimum, the tool call reports that a save dialog is open and waiting on the user.
This looks like the Electron default when no will-download handler sets a save path.
Why it matters
Saving documents from a signed-in site is a common agent job. Today the pane is the default browser for a desktop session and is where the user's sign-ins for that session live, but it cannot complete the job. The same download works with no dialog through Claude in Chrome (from a CLI session started with claude --chrome) and through Playwright, which is what we now use instead.
Environment
- Claude Desktop 2.16120.0 (Windows, MSIX), Code tab
- Browser pane user agent: Chrome/152.0.7977.130
- Windows 11 (10.0.26200)
- Seen consistently since at least August 2026
Also tried in the pane
- A
fetchPOST from an https page to a listener onlocalhost: refused (three variants), so bytes cannot be handed to a local process that way. - Returning the bytes as base64 through the JavaScript tool: works, but only for a file of a few kilobytes, since every byte passes through the model's context.