Repository navigation
Files panel: add upload to the file tree #9666
Description
Existing issues
- I searched open issues and this is not already requested.
Problem
What
The Files panel (both the sidebar Files tab and the full-page File Explorer app) can move files out of the workspace but not in.
Add drag-and-drop upload: drop a file from the OS onto a directory row in the tree and it is written to that path in the workspace, plus an Upload files... item on the directory row menu for people who do not want to drag.
Why: the asymmetry is already visible in the shipped strings
Download exists:
apps.fileExplorer.fileViewer.downloadcomponents.fileRenderers.download,.download_file,.office_download_originalcomponents.markdownPanel.download
It exists but is hard to reach: the only entry point is the viewer's unlabeled overflow menu, and it is absent from the file-tree row menu. That is filed separately as a discoverability issue; this request is strictly about the missing direction.
Upload does not exist at all. The complete apps.fileExplorer.* key set is 35 keys and contains no upload, drop, or new-file string. Row actions are chat, copy, open, reveal, resize, backend. Viewer actions are binary, copy, download, more, reload, select, sensitive, tip, truncated.
Meanwhile four other surfaces in the same dashboard already accept a dropped file:
components.chatInput.drop_to_attach/.upload_file— chat composerknowledge.sourcesList.drop_files_here_or_click_to_upload— Knowledge BasedesignCritique.composer.drop_screenshots_or_click_to_browse— Design Critique- the AWS Control file drive, shipped in feat(aws-control): drag and drop for the file drive #7983
So this is a consistency gap on one surface rather than a new capability for the product. The upload transport, the drop-zone UI pattern, and the server-side file write all already exist.
Why it matters
For anyone running the dashboard against a remote machine (Cloud Desktop, dev box, pod), the Files panel is the only file tool that already works, because it reads and writes through the gateway rather than the local filesystem. Every alternative for getting a file onto that machine is a separate stack with separate credentials.
Kiro IDE's Remote-SSH explorer accepts a dropped file and uploads it into the remote workspace. The dashboard's Files panel looks like that control and sits in the same position, but cannot do that one thing. That is where the expectation comes from.
Proposed behaviour
Proposed scope
- Drop onto a directory row writes into that directory. Drop onto a file row writes into its parent.
- A full-pane drop target while the Files tab has focus, mirroring the overlay from Add a full-pane drag-and-drop overlay for chat attachments #3242.
- An
Upload files...item on the tree's right-click menu for directory rows, which opens the OS file picker and writes the chosen files into that directory. In the sidebar Files tab that menu currently holds exactly one entry,Add to chat(the solectx_key inpages.chat.fileBrowserRail.*), added by feat(files): add "Add to chat" to the file-tree row menu #5380 — which is also the precedent for extending it. A click path is worth having alongside the drag gesture for two reasons: drag-and-drop advertises itself to nobody, and it cannot be driven from the keyboard. The Knowledge Base already pairs both on one surface, per its own stringdrop_files_here_or_click_to_upload. - Reuse the existing upload gates rather than inventing new ones: size limit, extension allowlist (fix: accept .har uploads in the dashboard file allowlist (#2555) #2676, fix(dashboard): accept .tsv and .jsonl uploads #8572), and the scanner-flagged-file consent path (feat(security): owner-consented delivery for scanner-flagged files #8780).
- A name collision should prompt, not silently overwrite.
Non-goals and open questions
- Not asking for drag out of the tree onto the OS desktop. Browsers cannot reliably originate a real file drag to the OS, and the existing viewer download already covers that direction.
- Should a dropped folder recurse? Dragging a folder into chat uploads it instead of inserting the path #743 and Support drag-and-drop to insert a file path instead of uploading the file #2355 show folder-drop semantics are contested even for the chat composer, so files-only may be the right first landing.
- Where should a write land when the tree is showing a capped or git-ignored view (Files panel cannot show git-ignored folders #8172, Files panel: 10k-file cap drops root-level folders from the tree #8173)?
Alternatives considered
No response
Anything else
Related
- Files panel: add right-click Download to the file tree #9665 (open) Companion request for the other direction:
Downloadis buried in the viewer's overflow menu and absent from the row menu. Together these two make the Files panel bidirectional. - feat(aws-control): drag and drop for the file drive #7983 (closed)
feat(aws-control): drag and drop for the file drive— closest precedent, same gesture, different surface - Add a full-pane drag-and-drop overlay for chat attachments #3242 (closed) full-pane drag-and-drop overlay for chat attachments — the overlay pattern to reuse
- feat(files): add "Add to chat" to the file-tree row menu #5380 (closed)
feat(files): add "Add to chat" to the file-tree row menu— shows the row menu is extensible - Add a Workspace Explorer panel to the dashboard for browsing project/workspace files #7051 (closed) and Dashboard: browse the full project file tree, not just pushed file paths #2781 (closed) — the issues that created the Files panel as a browse-only surface
- Support drag-and-drop to insert a file path instead of uploading the file #2355 (open) and Dragging a folder into chat uploads it instead of inserting the path #743 (closed) — drag-and-drop into chat, and path-versus-upload semantics; adjacent, not duplicates
Activity
github-actions commentedon Sep 9, 2026
Automated triage summary — generated from the issue text alone, before any maintainer has read it. Treat every line as a starting point, not a verdict.
Feature request: the Files panel (sidebar Files tab and full-page File Explorer) can only read/export files, so the reporter wants to add files into the workspace via drag-and-drop onto directory rows plus an "Upload files..." row-menu item, reusing the existing upload gates and collision prompts. Notes that four other dashboard surfaces already accept dropped files, making this a consistency gap, and matters most when running the dashboard against a remote machine.
Posted by
issue-summary.yml. The model had no access to the repository — it read only this issue and the titles of recent ones.iamwhatever commentedon Sep 9, 2026
🤖 Kiro Crew Auto-Pipeline [operator: iamwhatever]: Routing to
needs-human— the asymmetry is real and the precedents are correctly identified, but this request names its own open questions, and each one is a product ruling rather than an implementation detail.Verified against
main. The tree's row menu is extensible at one place —TreeContextMenuinwebsite/src/pierre/PierreWorkspaceTreeImpl.tsx, which today rendersctx_add_to_chatplus app-contributedtree-contextrows — so anUpload files...row has somewhere to go. The claim that the panel is write-out-only also holds.Why this cannot be auto-fixed. The issue itself leaves two questions open: whether a dropped folder recurses (and it notes the semantics are contested even for the chat composer, per #743 and #2355), and where a write lands when the tree is showing a capped or git-ignored view (#8172, #8173). Both change what the feature is. A third sits underneath them: reusing the existing upload gates means deciding which of them apply to a gateway-side write into an arbitrary workspace path — the size limit and extension allowlist are stated, but the scanner-consent path from #8780 was built for a different trust direction, and a collision prompt is new UI on a surface that has none.
Sequencing. Points 1-3 of the proposed scope are three separate landings (row-level drop, full-pane overlay, menu item + OS picker), and the menu item depends on the same row menu that #9672 reports as opening to nothing. A human should rule on folder semantics and the capped-view target first, then split this into the smallest shippable piece — most likely files-only drop onto a directory row, with the overlay and the picker following.
Not a duplicate. #9665 is the companion download direction; #7983 (closed) is the same gesture on the AWS Control file drive; #3242 (closed) is the overlay pattern.
amadsalmon commentedon Sep 9, 2026
Picking this up — opened #9749 for it.
Scope shipped there: drop onto a directory row (a file row resolves to its parent), a full-pane drop overlay, and an
Upload files…item on the directory row menu for the click/keyboard path. It reuses the existing admission gates rather than adding new ones (same extension allowlist, size cap, and magic-byte content-signature check as/api/upload/file, and/api/file-write's path/sensitive-path gate for the destination), and a name collision prompts instead of overwriting.On the two open questions in the description: folder drops are files-only for now, matching the non-goal you suggested, since #743/#2355 show folder semantics are still contested even for the composer. A write targets the real on-disk directory a row represents regardless of a capped or git-ignored view (#8172/#8173).
Two deliberate exclusions worth flagging: the standalone File Explorer app is untouched (separate process, read-only by design per its own manifest, so extending it is a materially larger change), and the scanner-flagged-file consent path from #8780 has no module in this codebase to reuse — no equivalent was invented, and the reasoning is recorded in the handler docstring.
KiroCrewCaptain commentedon Oct 8, 2026
Thanks for the report. This issue has been triaged by Crew Captain and will be assigned to a maintainer, who will follow up here.
KiroCrewCaptain commentedon Oct 13, 2026
There has been no activity here for a while. If you are still working on this, please leave a comment; otherwise a maintainer may pick it up so that it does not stall.