Before submitting
Area
apps/server
Problem or use case
Navigating above ~/ works, but mounted volumes never appear in the listing. Directories on an external drive or a second internal disk can't be reached through the picker at all. This is a common setup, since large repos and asset trees often sit off the boot drive for capacity reasons.
The Open In Explorer option sidesteps this, because the native dialog can reach any drive. It's only available when running at the host machine though, so remote sessions are left with the built-in picker and no way to select an external drive. Controlling agents from another machine or from the phone is a core use of T3 Code, and today that means physical access to the host before an external project can be added.
Environment
- T3 Code version: 0.0.33
- OS: Windows / MacOS
- Install method (npx / desktop / winget / brew):
Screenshot
Proposed solution
List mounted volumes in the picker and allow them to be selected like any other directory. Accepting a pasted absolute path in the path bar would largely cover it as well, if that isn't already supported.
Why this matters
Controlling agents from another machine or from the phone is a core use of T3 Code, and right now that use case can't reach a large share of the projects on the host. Anyone whose work lives on a secondary or external drive has to be physically at the machine to add it, which defeats the point of the remote client. Fixing it brings remote and local to parity for directory selection.
Smallest useful scope
Accepting a typed or pasted absolute path in the path bar. That requires no volume enumeration and no navigation changes, and it unblocks every case above. Listing volumes is the better experience, but path entry alone would be enough.
Alternatives considered
Open In Explorer works, but only at the host machine, so it doesn't help the remote case.
A symlink or junction inside home pointing at the external drive requires shell access on the host to set up, which is the same problem, and resolved paths may still land outside the picker's listing.
Mounting the external drive somewhere under the home directory is possible on macOS and Linux, but it's not a reasonable ask on Windows and it changes paths that other tools depend on.
Risks or tradeoffs
Enumeration has to happen server-side, since the client may be a browser or a phone on a different network. That rules out anything that leans on a native dialog.
A disconnected network mount can block in stat for 30 seconds or more, so the listing needs a timeout or it will lock up the picker.
A volume that errors on read should be skipped rather than failing the whole listing. Permission-denied paths and Windows junctions under the user profile both throw on read.
Volumes can disappear mid-session. A saved directory on a drive that's been unplugged should surface as unavailable rather than being silently dropped or recreated.
Widening what the picker can reach also widens what a remote client can browse, so it's worth deciding whether the exposed root should be configurable rather than unbounded.
Examples or references
Remote-first editors solve this the same way. VS Code Remote SSH and code-server both enumerate the host's volumes server-side rather than relying on a local file dialog.
Contribution
Before submitting
Area
apps/server
Problem or use case
Navigating above
~/works, but mounted volumes never appear in the listing. Directories on an external drive or a second internal disk can't be reached through the picker at all. This is a common setup, since large repos and asset trees often sit off the boot drive for capacity reasons.The Open In Explorer option sidesteps this, because the native dialog can reach any drive. It's only available when running at the host machine though, so remote sessions are left with the built-in picker and no way to select an external drive. Controlling agents from another machine or from the phone is a core use of T3 Code, and today that means physical access to the host before an external project can be added.
Environment
Screenshot
Proposed solution
List mounted volumes in the picker and allow them to be selected like any other directory. Accepting a pasted absolute path in the path bar would largely cover it as well, if that isn't already supported.
Why this matters
Controlling agents from another machine or from the phone is a core use of T3 Code, and right now that use case can't reach a large share of the projects on the host. Anyone whose work lives on a secondary or external drive has to be physically at the machine to add it, which defeats the point of the remote client. Fixing it brings remote and local to parity for directory selection.
Smallest useful scope
Accepting a typed or pasted absolute path in the path bar. That requires no volume enumeration and no navigation changes, and it unblocks every case above. Listing volumes is the better experience, but path entry alone would be enough.
Alternatives considered
Open In Explorer works, but only at the host machine, so it doesn't help the remote case.
A symlink or junction inside home pointing at the external drive requires shell access on the host to set up, which is the same problem, and resolved paths may still land outside the picker's listing.
Mounting the external drive somewhere under the home directory is possible on macOS and Linux, but it's not a reasonable ask on Windows and it changes paths that other tools depend on.
Risks or tradeoffs
Enumeration has to happen server-side, since the client may be a browser or a phone on a different network. That rules out anything that leans on a native dialog.
A disconnected network mount can block in stat for 30 seconds or more, so the listing needs a timeout or it will lock up the picker.
A volume that errors on read should be skipped rather than failing the whole listing. Permission-denied paths and Windows junctions under the user profile both throw on read.
Volumes can disappear mid-session. A saved directory on a drive that's been unplugged should surface as unavailable rather than being silently dropped or recreated.
Widening what the picker can reach also widens what a remote client can browse, so it's worth deciding whether the exposed root should be configurable rather than unbounded.
Examples or references
Remote-first editors solve this the same way. VS Code Remote SSH and code-server both enumerate the host's volumes server-side rather than relying on a local file dialog.
Contribution