[Bug]: Dropped folders become failed file uploads #11961

Activity

1. juliusmarminge commented on Sep 15, 2026

   

   juliusmarminge

   on Sep 15, 2026

   Member

   More actions

   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.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 15, 2026
3. juliusmarminge

   closed this as completedin #12001on Sep 16, 2026