[BUG] Claude in Chrome file_upload rejects scheduled-task sessions on Windows (same as closed #63334)

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 file_upload consistently fails with misleading "session not authorized" error — blocks photo upload and batch Excel import on a warehouse web app

Related issue: This appears to match anthropics/claude-code issue #63334 ("Claude in Chrome file_upload rejects all scheduled-task sessions with misleading error — real cause: INVALID_SESSION"). Adding a confirming report with a slightly different context (Cowork, not Claude Code CLI).

Environment

• Platform: Claude Cowork (Windows desktop app)
• Trigger context: a Cowork scheduled task invoking the claude-in-chrome MCP file_upload tool
• Target site: a third-party WMS (warehouse management system) web app, accessed via the Chrome extension

Summary

Prior to August 6, 2026, an automated scheduled task in Cowork reliably used file_upload to (a) attach inspection photos and (b) import a batch-shelving .xlsx file into file-input elements on our WMS web app. Starting August 6, 2026, the exact same workflow began failing 100% of the time, with no change on our end.

Error

Every call to file_upload, regardless of the file path format tried (Windows-style path, forward-slash path, or the session's internal Linux-style path), and regardless of whether the file lived in the session's own outputs directory or in a folder the user had explicitly connected/shared, returns:

Cannot upload "<file path>": only files this session is allowed to read can be uploaded. Ask the user to share the file with this session, or to add its folder with /add-dir.

Note: the /add-dir suggestion is a Claude Code CLI concept and does not apply in the Cowork environment, so the error message is actively misleading for Cowork users.

What we ruled out

1. Local folder permissions — the target files were confirmed readable/writable via the standard Read/Write tools in the same session; only file_upload specifically rejected them.
2. OS / browser version drift — user restarted the machine and fully uninstalled and reinstalled the Claude in Chrome extension. The error message was byte-for-byte identical before and after reinstall.
3. A shipped product update — checked the official Claude release notes (support.claude.com) for the surrounding period; no listed update touches the Claude in Chrome extension itself around August 6.

Why this points to a server-side session-validation regression

Because the error text did not change at all after a full extension reinstall, the failure is very unlikely to be caused by corrupted local extension state. This is consistent with issue #63334's root-cause description: file_upload's session validator apparently only recognizes interactive ("Cowork"/chat) session IDs, and returns INVALID_SESSION for sessions created by scheduled/background tasks — before ever reaching the folder-allowlist check. The generic wrapper then re-surfaces this as the "only files this session is allowed to read..." message, which sends users down the wrong troubleshooting path (permissions, folder sharing, extension reinstall) when the real cause is the session-type check itself.

Impact

Any Cowork scheduled task that needs to upload a local file through the Chrome extension (photo attachments, spreadsheet imports, etc.) is completely blocked. In our case this broke an unattended warehouse receiving workflow (photo-verified inspection + batch Excel import for putaway), forcing a fallback to manual, field-by-field data entry in the browser — a significant loss of automation value.

Steps to reproduce

1. Create a Cowork scheduled task whose prompt uses claude-in-chrome's file_upload tool to upload a file from the session's outputs folder (or a connected folder) into a file-input element on any web page.
2. Let the task run on its schedule (i.e., not as an interactive chat session).
3. Observe file_upload returning the "only files this session is allowed to read can be uploaded... add its folder with /add-dir" error regardless of path format.
4. (Optional, as we did) Fully reinstall the Claude in Chrome extension and repeat — the error is unchanged.

Ask

Could someone confirm whether this is the same root cause as #63334, and if there's a timeline for a fix or a supported workaround for scheduled-task sessions that need to upload local files via the Chrome extension?

What Should Happen?

Either:

(a) file_upload should succeed for Cowork scheduled-task sessions the same way it does for interactive chat sessions — i.e. the server-side session validator should recognize scheduled/background session IDs and check them against the folder allowlist, instead of rejecting them before the allowlist is ever consulted;

or at minimum

(b) the error message should surface the real underlying reason (e.g. an invalid/unrecognized session error) instead of masking it as "only files this session is allowed to read can be uploaded... add its folder with /add-dir" — the current message is actively misleading, since /add-dir isn't even a concept in Cowork, and it sends users down a dead-end path of re-checking folder permissions, restarting the app, and reinstalling the extension (all of which we tried, with no effect).

Error Messages/Logs

Cannot upload "/sessions/.../outputs/batch_shelf_REV26061770318.xlsx": only files this session is allowed to read can be uploaded. Ask the user to share the file with this session, or to add its folder with /add-dir.

This exact error was reproduced today (Aug 7, 2026) after fully uninstalling and reinstalling the Claude in Chrome extension — the error text was identical before and after reinstall, tested against both the session's own outputs folder and a user-connected folder.

Steps to Reproduce

1. In Claude Cowork (Windows desktop app), create a scheduled task (via the /schedule skill or the Scheduled Tasks UI) whose prompt instructs Claude to use the claude-in-chrome MCP's file_upload tool — specifically, to navigate to any web page with a file-input element (e.g. a form's "upload" button), locate that input via find/read_page, and call file_upload with a local file path.
2. Let the scheduled task fire on its cron schedule (i.e., the session is spawned automatically in the background, not started by the user typing in chat).
3. Inside that scheduled-task run, call file_upload with a path to a file that unambiguously belongs to the session — e.g. a file the session itself just created in its own outputs directory, or a file inside a folder the user has explicitly connected to Cowork.
4. Observe that file_upload fails 100% of the time with: Cannot upload "<path>": only files this session is allowed to read can be uploaded. Ask the user to share the file with this session, or to add its folder with /add-dir.
5. As a control, open a normal interactive chat session (not a scheduled task) in the same Cowork app, and call file_upload with the same file and the same target page — this succeeds normally, confirming the failure is specific to the scheduled-task session type, not the file, the page, or general extension health.
6. As a further control, fully uninstall and reinstall the Claude in Chrome Chrome extension, then repeat steps 1–4 — the error is reproduced identically, with byte-for-byte the same message, indicating the fault is not local/client-side state.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown exact version — regression observed starting August 6, 2026 (workflow was reliable for weeks prior, since mid-July 2026)

Claude Code Version

Version 1.26832.0 (056ee2)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Terminal/Shell: N/A — using Claude Desktop (Cowork mode), not the Claude Code CLI directly

The workflow was working normally through August 5, 2026, and started failing on August 6, 2026 with no code or configuration change on our end. We checked for any visible app/extension update around that time (Claude Desktop's own update mechanism, and the Chrome Web Store listing for Claude in Chrome) and found no indication of a version bump or changelog entry specifically around August 5–6 that would explain the change. The official Claude release notes (support.claude.com) also show no entry touching the Claude in Chrome extension in that window.

Given that a full uninstall/reinstall of the extension today did not change the error at all (see reproduction steps), we suspect this may correspond to a server-side deployment (e.g. a change to session validation logic) that isn't reflected in any user-facing changelog, rather than a client-side extension update. If a backend change did ship around August 5–6, 2026, that would be a useful data point for narrowing down the regression.

Current workaround: the affected scheduled task has been temporarily reconfigured to only extract data locally (screenshots + a prepared Excel file per receipt) into a staging folder, without attempting any WMS photo upload or batch import. A human then manually re-enters this data in the browser. This restores correctness but removes the automation's core value.

This is not an intermittent/rare failure — it is a 100% reproducible failure blocking every scheduled run since August 6, 2026 (the task runs every 3 hours). Before that, the same automated workflow had been running reliably for roughly three weeks (since mid-July 2026).

Note: the original issue #63334 was filed on macOS. This report confirms the same failure mode also occurs on Windows, suggesting the root cause is in shared/cross-platform session-management code rather than something OS-specific.

This may be part of a broader pattern of issues affecting Cowork/scheduled-task sessions specifically (as opposed to interactive chat sessions) — see also #47180 (scheduled tasks not respecting "Always allow" permissions) and #43397 (cloud scheduled tasks unable to load MCP connector tools).

Invalid input: expected array, received undefined

{
  "tabId": 1228032586,
  "ref": "ref_212",
  "paths": ["/Users/dhruvarora/Library/Application Support/Claude/local-agent-mode-sessions/7682385a-edf9-45b6-a826-c97aeba420a5/468e73ed-8a21-4dbe-a1ad-9e872bb7f90e/local_5448e3e7-537e-4967-88b4-aec8efab2bbc/outputs/file.pdf"]
}