Repository navigation
[Bug]: The composer refuses files that Claude Code and Codex accept by path #17471
Description
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.
T3.mp4
t3-cli.mp4
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 ([Bug]: DNG photos cannot be attached even as ordinary files #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 [Bug]: SVG image attachments are rejected by T3 Code #10936 and [Bug]: DNG photos cannot be attached even as ordinary files #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 @ 101f8b2)
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.
Activity
negentropi commentedon Oct 15, 2026
@t3dotgg where is your 1000pr per day?
feat(ui): reference dropped folders and oversized files by path
MyCoachCorey commentedon Nov 4, 2026
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.
joshrad-dev commentedon Nov 6, 2026
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.tsstill refuses any file larger thanfileAttachments.maxUploadBytes(50 MiB,PROVIDER_SEND_TURN_MAX_FILE_BYTES). Meanwhile,folderDrop.ts/addComposerFoldersalready insert a path viadesktopBridge.getPathForFilewhen the target is local. Reusing that path for files over the upload limit, whenfolderDropTarget(...)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
uploadfails 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.negentropi commentedon Nov 9, 2026
@t3dotgg 1mo now, this easy problem still unresolve. i though you ship at least 1500 pr per month.
heyzainali commentedon Nov 11, 2026
I'd like to fix option 2 from this issue as one focused PR, if that direction works for you.
In the desktop app on the local environment, a file over the upload limit would become a path link in the message, the same way folder drops already work through
folderDropTargetanddesktopBridge.getPathForFile. Drop, paste, and the attach button all go throughaddComposerAttachmentsinuseComposerAttachmentIntake.ts, so the change sits at that one size check.What stays the same:
ChatFileAttachmentschema, so there's no older-client decode problem like the one in fix: allow 100 MB file uploads without raising native media limits #15209.The agent gets what it gets today for an uploaded file: a path it reads with its own tools. The difference is that the file isn't copied into T3 home, so other clients see a path instead of a preview.
Does this direction work for you?
heyzainali commentedon Nov 11, 2026
Correction to my comment above: draft #22798 already proposes this oversized-file path link, together with the SVG change, so my note that it only covers SVGs was wrong. I've asked on #22798 how the maintainers want to handle it.
juliusmarminge commentedon Nov 12, 2026
Thanks for writing this up. It asks for new behaviour rather than reporting a defect, so it does not belong in the bug tracker and I'm closing it as not planned here. Feature ideas are discussed in Discussions: please post it there.