[BUG] Claude in Chrome `file_upload` rejects all scheduled-task sessions with misleading error (real cause: INVALID_SESSION)

I can confirm this with another local repro, and it looks like the issue is not Chrome file access or the target website's file input. It is the session boundary used by the Desktop/Chrome bridge.

Environment:

• Claude Desktop 1.9659.2 on macOS
• Claude in Chrome connected
• Target page: ChatGPT file input

What I observed:

1. In a normal Claude Code session, mcp__Claude_in_Chrome__file_upload is visible/callable, but every local path I tried failed with:

Cannot upload "...": only files the user has shared with this session can be uploaded.

This included files that were otherwise readable/attached in the Claude Code session.

1. In an interactive Cowork session, the same upload path works.

The successful session was a Cowork/local-agent-mode session titled File upload to ChatGPT. Its session id was local_<uuid>. The user-attached PDF was copied into that session's own:

~/Library/Application Support/Claude/local-agent-mode-sessions/.../local_<uuid>/uploads/<file>.pdf

Then this call succeeded:

{
  "tool": "mcp__Claude_in_Chrome__file_upload",
  "paths": [".../local_<uuid>/uploads/<file>.pdf"],
  "ref": "ref_187",
  "tabId": 1165646887
}

The returned result was:

Uploaded 1 file(s) to file input: <file>.pdf

Notably, userSelectedFolders was empty in the Cowork session metadata, so the success appears to come from the built-in allowlist for the current local session's uploads directory, not from a connected folder.

This matches the code-level diagnosis in this issue: the bridge is not simply checking whether the model can read the file. It is checking whether the current session is a recognized local/Cowork session and whether the file is under that session's allowed roots. When the session is not recognized by that manager, the user-facing error is flattened into the misleading "only files the user has shared" message.

This also clarifies the relationship to #31210 / #25871: those were about file_upload not being exposed. This is the next layer down: the tool is exposed and callable, but local path validation rejects sessions that are not registered in the same local-agent/Cowork session registry.

cc @bhosmer-ant since you confirmed the related MCP tool exposure fix in #12164. Could you route this to the Chrome/Desktop owner? The fix likely needs to either:

• make file_upload validate against all Desktop/Claude Code session managers that can expose the tool, or
• register these sessions in the same local-agent session registry used by Cowork, and
• preserve the real INVALID_SESSION reason in the user-facing error instead of masking it as a file-sharing problem.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Hit this exact failure today (2026-08-07) on a scheduled task session. file_upload rejected a path inside the session's own outputs folder with "only files this session is allowed to read can be uploaded" — matches the INVALID_SESSION root cause described above exactly. Session was spawned via the scheduler at 07:18 UTC; the rejected upload attempt was at 10:53. Can confirm the changelog fix for "Claude in Chrome file uploads failing for files in the session's shared folders and outputs" (shipped by v1.26832.0, 2026-08-06) did not resolve this — same error, one day later, same session type. Re-opening or at minimum surfacing the real INVALID_SESSION reason (suggestion 1 in the original report) would save others the same dead-end debugging. Happy to share more session logs if useful.

Also happening to me on mac now, it was working fine a week ago.

Landed here from the same tool failing a different way. On a normal interactive session mcp__claude-in-chrome__file_upload rejects the paths argument with expected array, received undefined on every call shape, which traces back to array arguments being serialized as strings (#22394, closed as not planned). Related CDP failure is documented in #32561.

Both of those are locked now, so leaving the working alternative here for anyone who arrives from a search.

Serve the file over loopback, fetch it inside the page, attach it through DataTransfer. That gives the input real bytes from disk rather than a synthetic in-memory file.

const input = document.querySelector('input[type=file]');
const blob = await (await fetch('http://127.0.0.1:8765/cover.jpg', {mode:'cors'})).blob();
const file = new File([blob], 'cover.jpg', {type: blob.type, lastModified: Date.now()});
const dt = new DataTransfer(); dt.items.add(file);
input.files = dt.files;
input.dispatchEvent(new Event('change', {bubbles: true}));

The non-obvious part is the server side. Chrome refuses a request from an https page to 127.0.0.1 unless the response carries Access-Control-Allow-Private-Network: true. Without that header the fetch neither resolves nor rejects, it just hangs with nothing in the console.

Server and page-side helper packaged here, MIT. https://github.com/kasparovabi/claude-file-bridge

Caveats. The change event is synthetic so isTrusted is false, and sites that verify event trust will refuse it, though ordinary upload forms accept it. A single long await fetch inside the javascript tool can also exceed the 45 second CDP evaluate timeout, so park the result on window and read it on the next call.

Used it for seven images in one session after every file_upload call failed.

Thanks for the workaround. Will try it within the next day or so.

Same root cause, but also reproducible from an interactive Cowork session (not just scheduled tasks) — and a newer client build now masks it as a schema error

I hit what looks like this exact bug, but from a normal interactive Cowork chat (no scheduled task involved), with a folder that was connected to the session. Sharing a clean reproduction in case it widens the scope here.

Environment

• Claude desktop app (Cowork mode) + Claude in Chrome extension, macOS, Google Chrome.
• Tool: mcp__claude-in-chrome__file_upload.
• App / extension versions: _<fill in — App → About; chrome://extensions → Details>_

Two symptoms, split purely by whether the file exists

file_upload({ tabId, ref, paths: [<one path>] }), connected folder, single file:

| paths value | file exists on disk? | result |
|---|---|---|
| ["test-dummy-value"] | no | only files this session is allowed to read can be uploaded |
| ["/tmp/nope.png"] | no | same "allowed to read" message |
| ["/Users/<user>/…/img.png"] (real file) | yes | -32602 Invalid arguments … "path": ["paths"], "message": "Invalid input: expected array, received undefined" |
| byte-identical copy of that file, renamed | yes | identical paths: undefined error |
| a freshly-created 69-byte 1×1 PNG in the same folder | yes | identical paths: undefined error |

Ruled out as causes by isolating one variable at a time: filename, file size (69 bytes fails), image content (byte-identical copy fails the same), extension (.png/.jpg), the folder, and home-directory path (a short /Users/<user>/test.png for a non-existent file passes). The only determinant is whether the file exists.

Why this looks like the same bug

• The non-existent-file path produces exactly the misleading "only files … allowed to read" message described in this issue, even though the folder was connected — i.e. the validator behaves as if nothing is shared, matching the session-manager mismatch in the root-cause analysis above.
• The existing-file path returns paths: expected array, received undefined. On a later call the tool itself returned: "file_upload can't accept pre-read files in this session; it only takes paths … the client converted them before they reached the host and file_upload is unavailable here — tell the user instead of retrying." So a newer client build appears to pre-read the file and convert paths → pre-read files before the host sees it; the host rejects the pre-read files, which surfaces as paths being undefined. Because only existing files get read, only existing files hit this — the "exists vs not" split above.

Net: same underlying session/validator failure this issue identifies, now surfacing one layer later (as a schema error) once the client started pre-reading files. The scheduled-task framing may be narrower than the actual blast radius — this reproduced in a plain interactive Cowork session.

Regression / persistence

Worked earlier in the same conversation (several successful uploads), then broke mid-session and did not recover after: page reloads, deleting and recreating the target draft, and a full quit-and-reopen of the desktop app, the Chrome extension, and Chrome. Every other Chrome MCP tool (navigate, javascript_tool, find, screenshot) kept working — only file_upload was affected.

Suggested diagnostic

If someone can check main.log around a failing call for INVALID_SESSION, that would confirm whether interactive Cowork sessions are being routed to the unrecognized manager the same way the scheduled-task sessions are.

Workarounds confirmed (don't touch file_upload)

• Native browser drag-and-drop / the site's own upload button.
• Rehosting from a public URL where the target site fetches the image server-side.
• upload_image is not a substitute — it only sources from a prior screenshot or a chat-uploaded image, not arbitrary local paths.

<img width="1200" height="628" alt="Image" src="https://github.com/user-attachments/assets/75a6fc30-7021-41c4-8287-9b2ab58ab8de" />