[Feature]: Support full folder management and drag-and-drop folder import

[isaachorowitz]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the request.

Area

apps/desktop

Problem or use case

T3 Code currently makes it difficult to manage folders from within the IDE. In particular, I cannot drag a folder from outside the app, such as from the Desktop or Finder, into the chat/workspace, and there is no straightforward in-app way to delete, rename, move, or otherwise manage folders.

This forces users to leave the IDE or use a separate file manager for basic workspace organization.

Expected behavior

Users should be able to:

• Drag a folder from Finder/Desktop into the chat or workspace to add/open it.
• Rename folders from an in-app folder/project control.
• Delete folders when appropriate, with a clear confirmation and safety warning.
• Move or otherwise organize folders from within the IDE where the operation is supported by the operating system.

The UI should clearly distinguish between removing a folder from T3 Code and deleting the folder from disk.

Smallest useful scope

Start with drag-and-drop folder import plus rename and remove/delete actions in the folder/project context menu. Keep destructive disk deletion behind an explicit confirmation.

Why this matters

Basic folder management is part of the core IDE workflow. Without it, users have to constantly switch between T3 Code and Finder/File Explorer for simple organization tasks.

Contribution

• I would be open to helping implement this.

[sieversjosua]

The folder-management part of this proposal is broad, but there is a useful smaller piece that stands on its own: dropping one folder from Finder or File Explorer onto the desktop app should add it as a project and open it.

If the path is already registered, the app should open the existing project instead of creating a duplicate. This would not rename, move, or delete anything on disk. It should also be limited to the primary local environment; SSH, WSL, and other remote environments should keep their current behavior.

I am considering a focused PR for only that interaction. Does that boundary fit the direction of the project, or would you prefer it to be tied to the open-path and CLI work in #7176?

[olafura]

This gist is a demonstration of how this feature could be built or customized with the Qt/QML branch. It is an example to try and adapt, not a complete implementation of the discussion request or a feature shipped in upstream T3 Code.

I expanded this into a working local folder-management example using the QML approach in #10708 and Qt's filesystem explorer pattern. The thread list stays visible alongside the browser and timeline, with no button needed to open the browser.

The example supports folder import, creating folders, renaming, same-filesystem moves within the chosen root, and confirmed system Trash. Files are listed read-only. Remove from T3 is a separate action that reuses the existing conversation-history deletion confirmation and leaves files on disk.

Registered project roots cannot be renamed, moved or trashed because that needs thread-path migration. Remote filesystem management, file editing and cross-filesystem moves are not implemented. Local access requires an owned backend or an explicit opt-in for a server confirmed to run on the same machine.

Runnable demonstration gist and setup.

Actual Qt windows on workspace 5 with disposable Atlas files and demo conversations, captured individually without changing workspaces.

Threads, the expanded file browser and the conversation are visible together. The file shown survived rename and move into archive/interface:

Moving a folder to system Trash requires typing its name. This changes files on disk and is separate from removing a project from T3:

Remove from T3 opens the existing history-deletion confirmation. It leaves files on disk. This confirmation was cancelled during validation:

Code and checks assisted by Codex.

[olafura]

Sorry for the lack of context this is showing how using this technique in the linked discussion would help with your issue #10708