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

[Operations-svg1]

Preflight Checklist

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

What's Wrong?

mcp__Claude_in_Chrome__file_upload rejects every file path when called from a Claude Code Desktop scheduled task, with a misleading error message:

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

The real cause (from main.log) is INVALID_SESSION, not a permission/sharing issue. Claude Desktop has two parallel session managers — CCD (used by scheduled tasks) and cowork (used by interactive chat) — and the Chrome MCP file_upload validator (Gv in app.asar) only consults the cowork manager (Ci). For CCD session IDs, Ci.getSession() returns null, so the validator throws [INVALID_SESSION] Unknown session: ... before ever reading the allowlist. The catch wrapper (Bcr / chromeFileUpload) re-emits this as the generic "shared with this session" message the user sees.

This makes file_upload structurally unusable from any CCD scheduled task. No permission/folder/sharing config the user can set will fix it — the session is rejected before the allowlist is consulted.

What Should Happen?

Either:

(a) file_upload should succeed for CCD scheduled-task sessions the same way it does for interactive cowork sessions — by having Gv consult both session managers (ln and Ci), and sourcing the allowlist for CCD sessions from the scheduled-task record's userSelectedFolders field (which is already preserved by the JSON writer but never read);

OR at minimum

(b) the error should surface the real INVALID_SESSION reason instead of masking it as "only files the user has shared". The current message sent me down hours of dead-end debugging trying to "share" the file in every conceivable way (which is impossible for CCD sessions — the validator throws before the allowlist is even checked).

Error Messages/Logs

From ~/Library/Logs/Claude/main.log (test run 2026-05-28):

2026-05-28 11:31:32 [info] Starting local session local_2baaad08-b19c-4a36-8565-fbf84e649d70 in /Users/mmhw/Downloads/MO
2026-05-28 11:31:33 [info] Mapping internal session local_2baaad08-... to CLI session 24635ca6-7c44-4fcd-afe6-2dc61c073d1f
2026-05-28 11:31:36 [info] [CCD start-timing] local_2baaad08-... preflight=801ms ... total_to_assistant=4343ms
...
2026-05-28 11:33:20 [warn] uploadLocalFile: unknown local agent mode session local_2baaad08-b19c-4a36-8565-fbf84e649d70
2026-05-28 11:33:20 [warn] [chromeFileUpload] rejected path for session local_2baaad08-b19c-4a36-8565-fbf84e649d70: /Users/mmhw/Downloads/MO/Standard Audio - Heidi.m4a ([INVALID_SESSION] Unknown session: local_2baaad08-b19c-4a36-8565-fbf84e649d70)

The [CCD start-timing] line confirms the session was spawned via the CCD path. The [chromeFileUpload] line shows the real INVALID_SESSION error that's then re-wrapped as the misleading user-facing message.

User-facing error returned to the SKILL:
> Cannot upload "/Users/mmhw/Downloads/MO/Standard Audio - Heidi.m4a": only files the user has shared with this session can be uploaded.

Steps to Reproduce

1. Have Claude Desktop running on macOS with the Claude in Chrome extension installed + connected + authenticated.
2. Create a CCD scheduled task — either via the /schedule skill, or by adding an entry to ~/Library/Application Support/Claude/claude-code-sessions//scheduled-tasks.json with cwd, cronExpression, and filePath pointing to a SKILL.md.
3. The SKILL.md should: open any web page containing an element via mcp__Claude_in_Chrome__navigate, find the input via mcp__Claude_in_Chrome__find, then call:
   mcp__Claude_in_Chrome__file_upload({
   paths: ["/Users//Downloads/anyfile.m4a"],
   ref: "",
   tabId:
   })
4. Wait for the cron to fire. file_upload returns the rejection error 100% of the time, regardless of file location.

Things I tried that did NOT fix it (all empirically verified):

• Adding userSelectedFolders: ["/Users/.../Downloads/MO"] to the task record in scheduled-tasks.json (preserved on disk; never propagated to the spawned CCD session JSON; validator throws INVALID_SESSION before reading allowlist anyway)
• Moving the file to /tmp, ~/.claude/, or the task's cwd
• @/folder mention in chat
• Restarting Claude Desktop

I traced the root cause in /Applications/Claude.app/Contents/Resources/app.asar → .vite/build/index.js: Gv only calls Ci.getSession() (cowork manager); CCD session IDs return null; Bcr wraps the thrown error as the generic catch-all message. The CCD buildSessionStartEvent schema (OXt) also explicitly drops userSelectedFolders / userSelectedFiles even when set on the scheduled-task record.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.149

Claude Code Version

Claude Code running inside Claude Desktop 1.9255.2

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Workaround in use: the affected task (tb-prep---heidi, daily 5 AM Heidi audio prep) now creates per-patient Heidi session shells with names pre-filled, then sends a desktop notification telling the user how many shells need manual audio upload + template application. The user opens each in their browser and does the file pick + template by hand.

Three suggested fixes ranked smallest → largest scope:

1. Surface the real INVALID_SESSION error to the user instead of masking it as "only files the user has shared". Even a one-line addition like "(INVALID_SESSION: this session manager isn't recognized by file_upload; this may be a CCD scheduled task)" would have saved hours of dead-end debugging.

2. Have Gv consult both session managers (ln and Ci). For CCD sessions, source the allowlist from the scheduled-task record's userSelectedFolders field (already preserved by the JSON writer; just never read on the spawn path).

3. Unify the spawn paths so CCD buildSessionStartEvent carries userSelectedFolders / userSelectedFiles through the same as cowork's, registers CCD sessions in a unified registry, and lets Gv work uniformly.

Relevant files for engineering:

• /Applications/Claude.app/Contents/Resources/app.asar → .vite/build/index.js (functions Gv, Bcr, OXt, Ci, ln, CCD vs cowork buildSessionStartEvent)
• ~/Library/Logs/Claude/main.log (the [chromeFileUpload] rejected path warnings)
• ~/Library/Application Support/Claude/claude-code-sessions//scheduled-tasks.json (CCD task records)
• ~/Library/Application Support/Claude/claude-code-sessions//local_.json (CCD session JSON — note userSelectedFolders key absent)
• ~/Library/Application Support/Claude/local-agent-mode-sessions//local_.json (cowork session JSON — userSelectedFolders: [] present as explicit empty array)

[Wangnov]

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.

2. 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: .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.

[github-actions]

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

[arjen-rave]

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.