[BUG] `claude-in-chrome` `file_upload` regressed in Claude Code 2.1.221 — two distinct failure modes in Cowork scheduled-task sessions (Windows)

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?

[BUG] claude-in-chrome file_upload regressed in Claude Code 2.1.221 — two distinct failure modes in Cowork scheduled-task sessions (Windows)

Preflight Checklist

• [x] I have searched existing issues. This is closely related to #63334 (macOS, INVALID_SESSION), but adds a second, distinct symptom (-32602 / paths: undefined) and a precise version regression boundary, so I am filing separately and cross-linking.
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code.

---

Summary

mcp__claude-in-chrome__file_upload worked reliably inside a Cowork scheduled task every day from 2026-07-17 through 2026-08-04 (Claude Code 2.1.209 → 2.1.219). Starting 2026-08-05 (2.1.221) it fails 100% of the time, and has continued to fail through 2.1.222.

The task definition did not change across the boundary — I diffed the two task prompts line by line and they are byte-identical (56 lines vs 56 lines, zero diff). Same model (claude-opus-5), same 90-tool set, same 11 MCP servers all reporting connected. The only thing that changed is the Claude Code version.

There are two different errors depending on where the file lives, and both are dead ends:

| File location | Result on 2.1.221+ |
|---|---|
| The session's own outputs\ / uploads\ directory | Error A — "only files this session is allowed to read" |
| A Cowork-connected user folder (e.g. Documents\ai-daily-news) | Error B — -32602 ... paths: expected array, received undefined |

Error A:

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.

Error B:

MCP error -32602: Input validation error: Invalid arguments for tool file_upload: [
  {
    "expected": "array",
    "code": "invalid_type",
    "path": [ "paths" ],
    "message": "Invalid input: expected array, received undefined"
  }
]

---

Environment

| | |
|---|---|
| OS | Windows 10 Home, build 19045 |
| Claude Desktop | 1.25927.0 (MSIX / Microsoft Store install), Electron 42.7.0 |
| Claude Code (CCD) | Working: 2.1.209, 2.1.215, 2.1.217, 2.1.219 · Broken: 2.1.221, 2.1.222 |
| Model | claude-opus-5 |
| Surface | Cowork scheduled task, cron 0 7 * * *, local session |
| MCP servers | All 11 connected, including claude-in-chrome |
| Target site | creator.xiaohongshu.com image-post publish page (authenticated, logged in) |

---

Evidence 1 — Version × outcome matrix (25 consecutive scheduled runs)

Extracted from audit.jsonl for every run of the same scheduled task. "Upload errors" counts only the two error strings above; the handful of -32602 hits before 2026-08-05 are an unrelated bash tool timeout_ms schema error.

| Date range | claude_code_version | file_upload outcome |
|---|---|---|
| 2026-07-17 → 07-19 | 2.1.209 | OK |
| 2026-07-20 → 07-21 | 2.1.215 | OK |
| 2026-07-22 → 07-26 | 2.1.217 | OK |
| 2026-07-27 → 08-04 | 2.1.219 | OK |
| 2026-08-05 → 08-08 | 2.1.221 / 2.1.222 | Fails 100% |

Neither error string appears even once in the 19 runs before 2026-08-05.

Evidence 2 — Near-identical calls, opposite outcomes

Last working call (2026-08-04, 2.1.219):

{"tabId":738940996,"ref":"ref_34",
 "paths":["C:\\Users\\<user>\\AppData\\Roaming\\Claude\\local-agent-mode-sessions\\<acct>\\<org>\\local_71855dc4-…\\outputs\\cover-2026-08-04.png"]}

→ Success. Zero errors in the entire session.

First failing call (2026-08-05, 2.1.221):

{"paths":["C:\\Users\\<user>\\AppData\\Roaming\\Claude\\local-agent-mode-sessions\\<acct>\\<org>\\local_11b08d4c-…\\outputs\\cover.png"],
 "ref":"ref_34","tabId":738941103}

→ Error A.

Same shape, same ref_34 from a fresh find, same session-owned outputs\ directory. The task prompt driving both runs is identical.

Evidence 3 — Controlled matrix (26 attempts on 2026-08-06, single session)

| Path | File exists | Result |
|---|---|---|
| session outputs\cover-2026-08-06.png | ✅ | Error A |
| session uploads\SKILL.md | ✅ | Error A |
| Documents\ai-daily-news\cover-2026-08-06.png | ✅ | Error B |
| Documents\ai-daily-news\cover.png | ✅ | Error B |
| Documents\ai-daily-news\tiny.png (168-byte PNG) | ✅ | Error B |
| Documents\ai-daily-news\doesnotexist.png | ❌ | Error A |
| /tmp/x.png, C:/x.png | ❌ | Error A |

Two things fall out of this:

1. Within the same allowed directory, existing files fail differently from non-existent ones. A file that is present returns -32602; a file that is absent returns the permission message. That inversion — the tool only -32602s on files it is actually supposed to be able to upload — suggests Error A is being used as a generic catch-all wrapper (consistent with the root cause traced in #63334), and that Error B fires further downstream, after the file has been read.

1. File size is not a factor. A 168-byte PNG fails identically to a 1242×1656 one, so this is not the 10 MB limit or any I/O/timeout issue.

Evidence 4 — Smoking gun for Error A

Cannot upload "C:/Users/<user>/AppData/Roaming/Claude/local-agent-mode-sessions/<acct>/<org>/local_bc9599a2-…/uploads/SKILL.md":
only files this session is allowed to read can be uploaded.

uploads\SKILL.md is this session's own scheduled-task definition file. It certainly exists and is certainly "shared with this session" — the runtime injected its contents into the session's first user message. If a session cannot read its own task file, the read-allowlist for scheduled-task sessions is not resolving at all.

This matches the root cause traced in #63334: the session lookup only consults the Cowork manager's getSession(), CCD session IDs return null, and the thrown error is wrapped as the generic catch-all message.

Evidence 5 — Error B is not the model omitting the argument

The client-side audit.jsonl record of the outgoing tool_use contains paths as a well-formed array:

{"type":"tool_use","name":"mcp__claude-in-chrome__file_upload",
 "input":{"paths":["C:/Users/<user>/Documents/ai-daily-news/cover-2026-08-08.png"],
          "ref":"ref_34","tabId":738941590}}

and the immediately following tool_result is the -32602 ... received undefined. So the argument is present when it leaves the client and missing when it is validated. This looks like the argument payload being transformed en route (e.g. paths consumed and replaced with file data after the allowlist check) and then re-validated against the original schema.

---

Steps to reproduce

1. On Windows, create a Cowork scheduled task (cron) whose skill file instructs Claude to:

• generate a PNG into a fixed local folder,
• navigate to any page with an <input type="file">,
• find the file input,
• call mcp__claude-in-chrome__file_upload({ paths: ["<absolute path>"], ref: "<ref>", tabId: <id> }).

1. Let the cron fire (do not run it interactively from a fresh chat).
2. Observe:

• path under the session's outputs\ or uploads\ → Error A
• path under a Cowork-connected user folder → Error B

Expected behavior

file_upload attaches the file to the target input, as it did on 2.1.219 and earlier.

---

Things ruled out (all empirically tested)

• Forward vs backslash path separators (both, plus escaped)
• Argument ordering (paths first vs paths last)
• Non-ASCII vs ASCII paths (Documents\AI每日新闻\ vs Documents\ai-daily-news\)
• File size (168-byte PNG behaves identically to a full-size cover)
• Wrong element (ref came from a fresh find immediately prior; page verified by screenshot to be on the image-post tab, logged in)
• Chrome restart, browser reconnect, retries
• Task prompt changes (byte-identical diff across the failure boundary)
• Output directory relocation (moving from session outputs\ to a connected folder only swaps Error A for Error B)

Not yet tested

Every one of my attempts occurred inside a scheduler-spawned session — including the interactive follow-up messages I sent, which were delivered into the same scheduler-created session. I have not yet tested file_upload from a manually started Cowork session. If that path works, it would confirm the defect is specific to scheduled-task sessions and match #63334's diagnosis.

---

Impact

This blocks any scheduled automation that uploads a locally generated artifact to an authenticated web app — the exact "generate nightly, post in the morning" pattern Cowork scheduled tasks are for. Because the agent naturally retries, each failed run also burns tokens (~$2–2.5 per run in my case).

Where to look

Per-session transcripts with full tool-call arguments are at:

%LOCALAPPDATA%\Packages\Claude_<pkg>\LocalCache\Roaming\Claude\
  local-agent-mode-sessions\<accountId>\<orgId>\local_<sessionId>\audit.jsonl

(Note: main.log does not record MCP tool-call arguments, so this bug is invisible there — worth knowing when triaging.)

Happy to supply the raw audit.jsonl files for the 08-04 (working) and 08-05 (first failure) runs on request.

---

Usernames, account/org UUIDs, and account names have been redacted; session UUIDs are truncated but internally consistent within this report.

What Should Happen?

Claude should upload the file to Chrome web site successfully

Error Messages/Logs

**Error A:**


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.


**Error B:**


MCP error -32602: Input validation error: Invalid arguments for tool file_upload: [
  {
    "expected": "array",
    "code": "invalid_type",
    "path": [ "paths" ],
    "message": "Invalid input: expected array, received undefined"
  }
]

Steps to Reproduce

Steps to reproduce

1. On Windows, create a Cowork scheduled task (cron) whose skill file instructs Claude to:

• generate a PNG into a fixed local folder,
• navigate to any page with an <input type="file">,
• find the file input,
• call mcp__claude-in-chrome__file_upload({ paths: ["<absolute path>"], ref: "<ref>", tabId: <id> }).

1. Let the cron fire (do not run it interactively from a fresh chat).
2. Observe:

• path under the session's outputs\ or uploads\ → Error A
• path under a Cowork-connected user folder → Error B

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.219

Claude Code Version

2.1.221 / 2.1.222

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_