Follow-up on #63334 — file_upload still broken, closed as "not planned" with no alternative path

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?

Follow-up on #63334 — file_upload still broken, closed as "not planned" with no alternative path

For posting as a new GitHub issue in anthropics/claude-code, or submitting via in-app feedback.

Suggested title

file_upload for scheduled-task (CCD) sessions still broken 3+ months after #63334 — closed "not planned" with no workaround available

Body

Filing as a fresh issue because #63334 was closed as "not planned" on 2026-08-11 and is not being tracked for a fix, but the underlying bug is still fully present and is blocking real production workflows.

Timeline:

2026-05-28 — #63334 opened. Root cause identified: Claude Desktop runs two parallel session managers (CCD for scheduled tasks, cowork for interactive chat). The file_upload validator only consults the cowork manager, so any scheduled-task (CCD) session is rejected with an internal INVALID_SESSION error before the file-sharing allowlist is ever checked. The user-facing error masks this as "only files the user has shared with this session can be uploaded," which sends users down a dead-end debugging path trying to "share" a file that was never going to be accepted regardless.
2026-08-11 — #63334 closed as "not planned," tagged stale.
2026-08-17 — Live re-test from a scheduled-task session: still fails, though now with a different error message than the original INVALID_SESSION-derived one (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...). Same net effect — completely unusable from a scheduled task — just a different failure signature, suggesting something changed under the hood without actually fixing the bug.
2026-08-24 — Re-tested again: identical new failure signature, fully reproducible, not a fluke.

Why this matters / business impact: This is not a theoretical annoyance — it's blocking three separate production scheduled tasks that need to deliver chart images or file attachments via Outlook web:

An intraday market-commentary task that wants to embed technical charts inline in an email.
A daily margin report task that wants to attach a regenerated Excel workbook and embed inline charts.
A daily P&L tracking task that wants to embed trend charts in its summary email.

All three have had to disable inline-image/attachment functionality entirely and fall back to delivering files through a separate mechanism outside the email, which is a materially worse user experience than what worked before this regression (this was explicitly called out in #63334 as "worked in a previous version," last known-good build 2.1.149).

Workarounds attempted and ruled out (so this doesn't get closed again with "have you tried X"):

Base64 data-URI image embedding: technically renders correctly, but costs on the order of 100K+ tokens per image to transmit through the browser-automation tool, making it cost-prohibitive for routine automated use.
Embedding an externally-hosted chart image via a plain <img src="https://..."> tag: the image is stripped by Outlook web's compose-box sanitizer on insertion, the same way it strips <style> blocks and class attributes from scripted DOM insertion.
Having the browser itself fetch the image and convert it client-side to a data-URI (to avoid the token cost of base64): blocked by Outlook's own page-level CSP, which prevents any outbound fetch() from the compose page to a non-Microsoft domain.

None of these are viable substitutes for a working file_upload, which would let the file go through Outlook's own legitimate image/attachment upload pipeline instead of a scripted workaround.

Ask:

Reopen #63334, or treat this as its replacement, given the bug is still 100% reproducible and is actively blocking production use, not merely inconvenient.
At minimum, per the original report's smallest-scope suggested fix: surface the real INVALID_SESSION (or whatever the current internal error actually is) to the user/model instead of a generic, misleading permission-style message — this alone would save significant debugging time for anyone hitting this next.

Happy to provide additional repro details, logs, or a fresh minimal reproduction if useful.

What Should Happen?

file_upload` should succeed for scheduled-task sessions the same way it does for interactive sessions, OR at minimum the error message should say what's actually happening instead of a generic/misleading message — same two options #63334 originally proposed.

Error Messages/Logs

Original error, as documented in #63334 (opened 2026-05-28):

Cannot upload "/path/to/file": only files the user has shared with this session can be uploaded.
(Underlying cause per main.log: [INVALID_SESSION] Unknown session: <session-id>)

New error, reproduced independently on 2026-08-17 and again on 2026-08-24 (same wording both times):

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.

Steps to Reproduce

1. From a Claude Desktop scheduled task (or any session using the CCD session manager), use the Claude in Chrome tools to navigate to any page with a file input.
2. Locate the file input element (e.g. via the find tool).
3. Call file_upload with that element's ref and a valid file path that the session has access to (a file in the Downloads folder or a Cowork-connected folder both fail identically).
4. Observe the error above — happens every time, regardless of file location, file type, or how recently the fil

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.149, per #63334 (not independently re-verified by us — we don't have a pre-regression build to test against).

Claude Code Version

[fill in from Claude Desktop's About/Help screen before submitting — not visible from within a session] to test against).

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

hree of my scheduled tasks (an intraday market-commentary note, a daily margin report, and a daily P&L tracker) all rely on getting chart images or file attachments into Outlook web emails, and have had to disable that functionality entirely because of this bug. I also tested three separate workarounds to avoid needing file_upload at all — base64 image embedding (~100K+ tokens per image, cost-prohibitive), externally-hosted image URLs (stripped by Outlook's own compose-box sanitizer), and browser-side fetch-to-data-URI (blocked by Outlook's page CSP) — none of which are viable substitutes for a working file_upload.