[Bug] file_upload unusable from Claude Code surface — no input channel registers files

Summary

mcp__claude-in-chrome__file_upload checks an in-memory registry of files "shared with this session." In the Claude Code surface running inside Claude Desktop (CLAUDE_CODE_ENTRYPOINT=claude-desktop), none of the available input channels populate that registry. Every call rejects with:

Cannot upload [path]: only files the user has shared with this session can be uploaded.

Tested six channels live (2026-05-24 ~22:30–23:00 ET):

| Channel | Read tool gets file? | file_upload accepts? | UUID-prefix copy on disk? |
|---|---|---|---|
| Canonical host path (no sharing) | yes (Read passthrough) | NO | no |
| bash cp into Claude Desktop sandbox uploads/ | n/a | NO | no |
| bash cp into Claude Code /private/tmp/claude-501/.../uploads/ | n/a | NO | no |
| Drag-drop into chat input | yes | NO | no |
| Typed @-reference in chat input (×2) | yes | NO | no |
| mcp__ccd_directory__request_directory grant on parent dir | n/a | NO | no |

The Read-tool inline-attachment channel (drag-drop, @-reference) and the file_upload registry are wired separately. The Read tool sees the file; file_upload does not. The request_directory grant message explicitly scopes itself to "Read/Write/Edit/Grep/Glob" — file_upload is not in that list.

The historical disk record shows UUID-prefix-copy artifacts exist (the canonical signature of a successful registration is <uuid>-<epoch-ms>_<original-filename> under the session's uploads/), but the most recent one on this machine is from 2026-05-16, eight days before this report. Those appear to originate from the standalone Claude Desktop chat surface, not the Claude Code surface — and they don't appear to cross-pollinate.

Net effect: file_upload is currently a dead end for any workflow running through Claude Code. Users have no documented programmatic path to register files, and no UI gesture in the Claude Code chat surface works either.

Environment

• Claude Desktop: 1.8555.2
• OS: macOS 25.5.0 (Darwin)
• CLAUDE_CODE_ENTRYPOINT=claude-desktop
• CLAUDE_AGENT_SDK_VERSION=0.3.149

Reproduction steps

1. Open a chat in Claude Desktop.
2. Drag-drop a PDF (e.g., pathmark-02-missions-companion.pdf) from Finder onto the chat input.
3. Observe: an @-style attachment chip appears, and the model receives a Read-tool reminder for the file. The file IS visible in context. So far, expected.
4. Ask Claude to upload the same PDF via mcp__claude-in-chrome__file_upload, passing the file's path (any plausible path: original Finder path, expected session uploads/ path, etc.).
5. Observe: file_upload rejects with "Cannot upload [path]: only files the user has shared with this session can be uploaded."
6. Filesystem check:

``bash
find ~/Library/Application\ Support/Claude/local-agent-mode-sessions \
-name "*<original-filename>" 2>/dev/null
`
Returns **zero results**. The drag-drop never landed a UUID-prefixed copy in any session's uploads/` directory.

1. Repeat the entire flow using the paperclip attachment button instead of drag-drop. The paperclip-shared file appears at <session-sandbox>/uploads/<uuid>-<epoch-ms>_<original-filename>.<ext> and file_upload accepts it — but only when the paperclip is invoked from the standalone Claude Desktop chat surface, not from Claude Code.

Expected behavior

Drag-drop and @-reference into the Claude Code chat input should register the file with file_upload's in-memory registry so the tool accepts it — matching the paperclip code path and matching user expectation that "I shared this file with the session."

Actual behavior

Drag-drop and @-reference register the file with the Read tool only. file_upload continues to reject every path (canonical, sandbox uploads/, sandbox outputs/, anywhere) because the file was never registered with file_upload's separate registry.

Disk evidence

After drag-dropping pathmark-02-missions-companion.pdf (and four other Pathmark Companion PDFs) into the chat multiple times on 2026-05-24 ~22:00–22:30 ET, and after two further @-reference attempts at 22:55 and 22:58 ET:

• Read-tool @-style reminders fired correctly for each share attempt.
• Filesystem scan across the entire ~/Library/Application Support/Claude/local-agent-mode-sessions/ tree returned zero UUID-prefixed copies of any pathmark-*.pdf.
• Compare: paperclip-shared files from earlier sessions (e.g., Mayflower Church Constitution and Bylaws - March 2026.docx, bookends-attachment-report.csv, The Sheet Came Down — Acts 10.9-33.docx) do appear at local_<sessionUUID>/uploads/ with the expected <uuid>-<epoch-ms>_<original-filename> naming.

The on-disk signature confirms drag-drop and @-reference do not invoke the pipeline that writes paperclip-shared files into the session sandbox.

Related design gap — request_directory does NOT extend to file_upload

While diagnosing this bug we tested whether mcp__ccd_directory__request_directory could serve as the programmatic workaround. It does not. The grant message reads:

Folder access granted: <path>

Use this exact path with Read/Write/Edit/Grep/Glob.

file_upload is explicitly absent from that scope. We confirmed live: after a successful request_directory grant on the file's parent directory, calling file_upload with the file's canonical iCloud path is still rejected with the same allowlist error.

This may be intentional (the user only consented to file reading, not outbound transmission). If so, please clarify in the request_directory documentation that it does not extend to file_upload, since the agent has no other documented programmatic path to register files. If it is unintentional, please consider extending the grant to cover file_upload for files inside the approved directory — the alternative is forcing the user to paperclip-share every file individually, which does not scale for batch uploads (10+ files into a course platform, etc.).

Suggested fixes (any of)

1. Make drag-drop and @-reference call the same registration pipeline as the paperclip button. Simplest fix; matches user expectation; closes the channel split.
2. Bridge the standalone Claude Desktop and Claude Code surfaces' file registries. If the paperclip pipeline only exists in standalone, then the Claude Code surface should be able to either reuse it or trigger it.
3. Either extend request_directory to cover file_upload, or document that it doesn't.
4. Update the file_upload tool description and error message to tell the model and user which input channels actually register files, since the current description ("attachments, the session's outputs/uploads folders, or folders the user has connected") is empirically wrong from the Claude Code surface.
5. Add a visible "registered with session" indicator in the chat UI for shared files so users can see the difference between Read-tool-only attachments and fully-registered uploads before they try to use them downstream.

Adjacent / related issues

• #31210 — file_upload tool not exposed via Claude Code MCP connection (now partly resolved; tool reaches the runtime, this issue is the next layer down).
• #38811 — 18 of 20 Chrome MCP tools blocked by enabledMcpTools (confirms file_upload is reachable; this issue is about its registration semantics).

Impact

For automation flows that use mcp__claude-in-chrome__file_upload from Claude Code to push artifacts into web apps (LMS uploads, form attachments, document portals, etc.), file_upload is currently completely unusable.

Severity: this looks like P1 (blocks a core advertised capability) rather than P2 (poor UX). The tool ships, the schema is exposed, the description promises that drag-drop / uploads/ / connected folders will work, and none of them do from the Claude Code surface.