[BUG] Claude in Chrome file_upload fails in interactive Cowork session — rejects paths before reaching the page

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?

Claude in Chrome's file_upload tool fails in a normal INTERACTIVE Cowork session (not a scheduled task) with a generic, structurally-blocking error. No file ever reaches the target page.

Environment:

• Client: Claude Desktop, Cowork, interactive session
• - Claude in Chrome extension, connected and authenticated
• - - OS: macOS
• - - - Target site tested: gemini.google.com (repro also confirmed against a file placed directly in the session's own outputs folder, ruling out a Downloads-folder-specific cause)

Steps to reproduce:

1. In a Cowork session with a folder connected (e.g. ~/Downloads) and Claude in Chrome available, navigate to a site with a file upload input (gemini.google.com > "Upload & tools" > "Upload files").
2. 2. Use find/read_page to get the file input's ref.
3. 3. Call file_upload with an absolute path to a file inside the connected Downloads folder.
4. 4. Result: Cannot upload "...": only files this session is allowed to read can be uploaded.
5. 5. Copy the same file into the session's own outputs folder (a location the session unambiguously owns/created) and retry file_upload with that path.
6. 6. Result changes to a different, more revealing error: file_upload can't accept pre-read files in this session; it only takes paths of files in folders the user has connected to the session. If you passed paths and still see this, the client converted them before they reached the host and file_upload is unavailable here — tell the user instead of retrying.
7. 7. Retried again against the original Downloads path (with the exact filename bytes, including a narrow no-break space character, correctly escaped) — same error as step 6.

Why this looks like a distinct/new variant:

• Not the scheduled-task session bug in #63334 — this was a normal interactive session.
• - Not simply the CDP "Not allowed" error in #32561 — different error text, and the tool's own message states the client already converted/rejected the paths before they reached the host, i.e. the failure is upstream of any CDP call.
• - - This suggests a third broken code path in file_upload's session/path validation, distinct from the two already-filed variants.

Impact: file_upload is completely non-functional for interactive Cowork sessions in this environment, blocking any workflow where Claude needs to upload a local file to a website on the user's behalf.

Related issues: #31210, #32561, #63334, #15651

Edit: GitHub's duplicate-detector surfaced #85517, which is closely related but not identical — that report is Windows-only and shows a schema-validation error (-32602 "paths ... received undefined"). This report is macOS, and shows a third, distinct error message ("file_upload can't accept pre-read files in this session ... file_upload is unavailable here") that doesn't appear in #85517, #84880, #85107, #63334, or #32561. Flagging both so they can be correlated rather than treated as true duplicates.

What Should Happen?

file_upload should successfully attach the file at the given path to the target <input type="file"> element whenever the path is inside a folder connected to the session, or inside the session's own outputs folder — instead of failing with a generic, client-side rejection that occurs before the file ever reaches the host/CDP layer.

Error Messages/Logs

Attempt 1 (Downloads path):
Cannot upload "/Users/agentpop/Downloads/Screenshot 2026-08-21 at 4.56.05 PM.png": only files this session is allowed to read can be uploaded.

Attempt 2 (session outputs-folder path, after copying the same file there):
file_upload can't accept pre-read `files` in this session; it only takes `paths` of files in folders the user has connected to the session. If you passed paths and still see this, the client converted them before they reached the host and file_upload is unavailable here — tell the user instead of retrying.

Attempt 3 (Downloads path again, filename bytes corrected):
Same error as Attempt 2.

Steps to Reproduce

1. On macOS, in Claude Desktop's Cowork mode, connect a folder (e.g. ~/Downloads) that contains an image file, with the Claude in Chrome extension connected and authenticated.
2. In a normal interactive session (not a scheduled task), navigate Chrome to https://gemini.google.com/app
3. Click the "+" / "Upload & tools" control, then "Upload files" to reveal the hidden file input.
4. Use find/read_page to get the file input element's ref.
5. Call file_upload with paths pointing at the image file's absolute path inside the connected Downloads folder, plus the ref and tabId.
6. Observe: Cannot upload "...": only files this session is allowed to read can be uploaded.
7. Copy the exact same file into the session's own outputs folder (a location the session created and unambiguously owns) and retry file_upload with that new path.
8. Observe a second, different error: file_upload can't accept pre-read files in this session; it only takes paths of files in folders the user has connected to the session. If you passed paths and still see this, the client converted them before they reached the host and file_upload is unavailable here.
9. Retry once more against the original Downloads path, with the filename's exact bytes (it contained a narrow no-break space, U+202F) correctly escaped — same error as the previous step.
10. No file ever reaches Gemini's upload input at any point.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Unknown — Claude Desktop / Cowork mode (not invoked via CLI, so claude --version isn't applicable). App auto-updates; date of repro: 2026-08-22.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Non-interactive/CI environment

Additional Information

Filed after researching the issue tracker and finding this is a known, longstanding problem (open since March 2026) rather than a documented/intentional limitation — Anthropic's own docs describe file upload to websites as a supported use case. None of the previously-filed variants' workarounds apply here: upload_image only works with in-session screenshots, JS-injected base64 files get rejected by trust-checking sites, and the native OS file picker isn't interactable by the agent.