[Bug]: Dropped folders become failed file uploads

[caiopizzol]

Before submitting

• I searched existing issues. Related reports are linked below.
• I included reproduction steps and supporting evidence.

Area

apps/web — shared by web and desktop. Observed on desktop and reproduced in the browser.

Steps to reproduce

1. Open a chat in T3 Code.
2. Drag any folder from your computer into the message composer.

Expected behavior

I expect a folder reference or path, as Codex desktop displays. If the selected client or environment cannot support that, explain the limitation without creating a failed attachment.

Actual behavior

T3 treats the folder as a file attachment and shows upload failed. Send becomes disabled with the label Retry or remove the failed attachment.

Dropping an ordinary text file into the same composer uploads successfully.

Impact

Minor bug or occasional failure. Sending is blocked until the failed attachment is removed.

Version or commit

Browser reproduction: main at 3efdcc529, package version 0.0.40. Original desktop version not recorded.

Environment

Ubuntu 26.04 LTS, Chromium 143.0.7499.4, Node.js 24.18.0; local T3 server. Browser reproduction used Playwright 1.61.1 and Chromium's native drag API with a real filesystem folder.

Logs or stack traces

Regular file: upload HTTP 204; Send enabled
Folder: isDirectory=true; upload net::ERR_FILE_NOT_FOUND; Send disabled

The browser identifies the dropped item as a directory, but the shared drop handler forwards it to the attachment uploader without checking directory entries.

Screenshots, recordings, or supporting files

Screenshots collected for this report:

• failed folder upload on desktop

• successful file upload beside the failed folder upload

• the folder appears as a Folder reference in Codex desktop; version not recorded.

Codex CLI 0.154.0 and Claude Code 2.1.269 also accept pasted folder paths as editable text. These were paste checks, not drag-and-drop tests. Claude Desktop was not tested.

Workaround

Remove the failed attachment and paste the folder path as text. This re-enabled Send in the browser test. The path must be accessible to the selected environment.

Related reports

• [Feature]: Support full folder management and drag-and-drop folder import #6138: broader folder import and management request, closed.
• [Feature]: Pasting paths into prompt window. #1863: automatic path pasting, declined due to platform-specific clipboard/privacy behavior and the existing @ path flow. This report concerns the failed upload; the choice of folder-reference behavior remains open.

[juliusmarminge]

Triage

Confirmed on current main (3efdcc529). Dropping a folder onto the chat (web or desktop) is treated as a file attachment, the upload fails, and Send stays blocked until that chip is removed. Regular file drops still work.

What happens

makeWorkspaceFileDropHandlers only looks at dataTransfer.files and forwards every entry to the composer:

    onDrop(event: WorkspaceFileDragEvent) {
      if (!isFileDrag(event)) return;
      event.preventDefault();
      host.setDragActive(false);
      host.addFiles(Array.from(event.dataTransfer.files));
    },

WorkspaceFileDragEvent does not expose dataTransfer.items, so the handler cannot see webkitGetAsEntry().isDirectory / getAsFileSystemHandle(). Chromium still puts a File for the folder into .files (often with a non-empty size and empty MIME type).

That File then follows the normal attachment path:

1. ChatView / sidebar rows call composerRef.addDroppedFiles → addComposerAttachments
2. classifyComposerAttachmentFile treats empty MIME as a generic "file"
3. If file.size > 0, it is staged (the size <= 0 guard does not save this case)
4. attachmentUploadQueue does xhr.send(file); Chromium cannot read a directory blob (net::ERR_FILE_NOT_FOUND)
5. Upload state becomes failed → chip shows upload failed → attachmentUploadBlockReason returns Retry or remove the failed attachment

The same drop helper is reused for sidebar thread drops (Sidebar.tsx, LegacySidebar.tsx), so those fail the same way. The attach-file picker is type="file" without webkitdirectory, so this is drop-specific.

Related, not duplicates

• [Feature]: Support full folder management and drag-and-drop folder import #6138 (closed) — broader folder import/management
• [Feature]: Pasting paths into prompt window. #1863 (closed) — path paste declined (clipboard/privacy; @ mentions already cover workspace paths)
• feat(web): accept file drops across the chat workspace #6636 (merged) — added workspace file drops; files only
• feat(web): accept file drops into sidebar threads #7892 (merged) — sidebar drops reuse this helper
• Closed path-mention PRs (Insert file mentions when non-image files are dropped on the composer #5390, feat(web): insert path mentions for non-image file drops and pastes #5543, feat(composer): drop non-image files as filesystem paths #7749, feat(composer): drop non-image files as filesystem paths #8549) — earlier “insert a path instead of attaching” work; not a live fix. Generic file attachments shipped after those.

No open PR matches this folder-drop → failed-upload path.

Suggested fix

Keep this as a bugfix, not a folder-import feature:

• In workspaceFileDrop, inspect dataTransfer.items and skip directory entries before addFiles
• Mixed drops: attach real files, ignore folders
• Optional toast: folders cannot be attached; use @ or paste a path
• Unit-test a directory DataTransferItem so it never reaches addFiles

Codex-style folder references can stay a separate enhancement. Even without that, a dropped folder should not create a failed attachment that blocks Send.

Workaround: remove the failed chip, then paste the path or @-mention something in the workspace.