Synced from GitHub
@t3dotgg where is your 1000pr per day?
[Bug]: The composer refuses files that Claude Code and Codex accept by path#17471
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
In the desktop app on the local environment, with Claude or Codex selected:
- Drag an SVG onto the composer.
- Drag a file larger than 50 MB, such as a screen recording, onto the composer.
- Drag a folder onto the composer.
To compare, give Claude Code 2.1.295 or Codex CLI 0.161.0 the same three paths in a terminal.
https://github.com/user-attachments/assets/db415a1b-996f-4086-9063-d3b6cb7fd33d
https://github.com/user-attachments/assets/41ed044d-6ce7-4dfd-b6d4-ba5a0afb8245
Expected behavior
T3 Code accepts what the CLIs it wraps accept. Given the path of an SVG, a 60 MB file, or a folder, both CLIs let the agent read it with its own tools. T3 Code should give the agent those items the same way, even when it can't preview them or upload a copy.
Actual behavior
| Item | Claude Code and Codex CLI | T3 Code |
|---|---|---|
| SVG | The agent reads it | Refused: 'image.svg' is not a supported image type. Attach GIF, HEIC, HEIF, JPEG, PNG, or WebP images. |
| 60 MB video | The agent reads it | Refused: 'big-video.mov' exceeds the 50 MB attachment limit. |
| Folder | The agent lists it | Becomes a path link and the agent gets the path. Clicking the link shows The path is a directory or special file, not a regular file. (#15215) |
I checked the CLI column by giving each CLI the three paths in one prompt. Both reported the SVG's fill color, the file's size, and the folder's contents.
Why it happens
The CLIs pass paths. T3 Code's composer uploads a copy of each dropped file and refuses anything it can't upload:
classifyComposerAttachmentFilemarks anyimage/*type other than GIF, JPEG, PNG, WebP, and HEIC as unsupported, andaddComposerAttachmentsrefuses it.- The same function refuses ordinary files over the server's
maxUploadBytes(50 MiB).
The upload doesn't decide what the agent can use. For ordinary files, every adapter adds [Attached file "…" is saved at: <path>] to the prompt, and the agent reads that path, as it would in the CLI. The server already accepts image/svg+xml as an ordinary file, which is why renaming an SVG to .txt works (#10936). Folders already skip the upload: on the local environment, the desktop app inserts the folder's path.
Why this hurts
- T3 Code wraps these CLIs. When it refuses an input the CLI accepts, the wrapper gets in the user's way.
- Users fall back to workarounds: renaming the file, converting it (#16023), copying it into the workspace, or typing its path.
- The SVG error steers users to raster formats, which throw away the design source.
- On the local environment, the file is already on the disk the agent reads. The 50 MB limit protects an upload the agent doesn't need.
Possible direction
- On all surfaces, stage unsupported image types as ordinary files instead of refusing them. This resolves #10936 and #16023.
- In the desktop app on the local environment, insert a path link for a file over the upload limit, as folder drops already do.
- In the browser and on remote environments, a local path means nothing to the agent. Keep the refusal there, and suggest an
@mention or a typed path.
Impact
Major degradation or frequent failure
Version or commit
0.0.46-nightly.20261007.2774 (main @ 101f8b2f5)
Environment
macOS 26.7, desktop app, local environment, Claude Opus 5.5. CLI comparison: Claude Code 2.1.295, Codex CLI 0.161.0.
Workaround
Rename the file to .txt, copy it into the workspace and @-mention it, or type its absolute path.
Related
#10936, #16023, #15215, #11961 and #12001 (folder drops)
P.S. I understand why T3 Code uploads attachments: a copy on the server can be opened from any client, including mobile and remote ones. That's a good reason to upload a file. It isn't a reason to refuse one just because T3 Code can't preview it or send it to the model as an image. T3 Code already uploads ZIPs and other binary files it can't render, so an SVG or a DNG can take the same path.
Synced from GitHub
Another real case for folders. I dragged a client project folder from Finder into the composer on macOS desktop so the agent could organize it. The folder held 13 files: PDFs, a .pages doc, a markdown note and an 86 MB call recording. T3 refused it. The only workaround was pasting the folder's path as text, and then the agent read the folder fine with its own tools.
It would be enough to turn a dropped folder (and any file too large to upload) into a path reference in the message, like the CLIs do. Nothing needs to be uploaded.
Synced from GitHub
Confirming on v0.1.7 (desktop app, local server, macOS 27.0 arm64). Dragging a file over 50 MB onto the composer still shows '<file>' exceeds the 50 MB attachment limit.
In the v0.1.7 source, useComposerAttachmentIntake.ts still refuses any file larger than fileAttachments.maxUploadBytes (50 MiB, PROVIDER_SEND_TURN_MAX_FILE_BYTES). Meanwhile, folderDrop.ts / addComposerFolders already insert a path via desktopBridge.getPathForFile when the target is local. Reusing that path for files over the upload limit, when folderDropTarget(...) returns "local", would match how Codex and Claude Code handle drag-and-drop: they just insert the path.
Related: #30287 is the same pattern in a different place. Preview upload fails over 50 MB because Playwright copies the file's bytes instead of passing its path, even though the browser and server share a filesystem. Both could use one "is this client on the server's machine?" check to decide between passing a path and uploading a copy.
Comment drafted with Claude Code (Claude Opus 5.5) via t3 triage.
Synced from GitHub
@t3dotgg 1mo now, this easy problem still unresolve. i though you ship at least 1500 pr per month.