Mount folders

A sandbox cannot see your computer. It reaches a folder only if you mount it, and mounting is how a project gets into Work — the equivalent of Add project on Code, which browses your disk directly.

Mounting one

Mount project opens the same dialog from three places: the folder button beside Projects in the Work sidebar, the server's menu entry in Settings → Servers, and Mount project on the new-session screen.

Pick a folder on this computer and save. Every mounted folder appears as its own project on the sandbox, and mounts are read-write — the agent edits files in them without asking.

The folder the sandbox was created with is fixed for its life and is always mounted. Everything else you add can be removed again.

The dialog waits for the sandbox's state before it builds its list, so opening it moments after launch shows what is actually mounted rather than an empty list it would then save back over the top.

Unmounting

A mounted folder's project menu on Work offers Unmount, in red. It does what it says: the folder leaves the sandbox and the row goes with it. Mounting the folder again brings the project back — and its sessions with it, because those live inside the sandbox, not in the folder.

Unmounting closes that folder's sessions and drafts along with its project row, whether you unmount from the folder's own menu or by removing it in the Mount project dialog. Otherwise a conversation would stay on screen belonging to a folder the sandbox can no longer see.

The project folder the sandbox was created with offers neither Unmount nor Close — deleting the sandbox is the way to be rid of that one. Code projects keep Close, which only takes the row out of the sidebar and is unchanged.

Tabs, per folder

A sandbox can mount several folders, and each keeps its own session tabs. Clicking a folder in the sidebar takes you back to the session you were last in there — or to that folder's draft, or one of its open tabs, and only to a fresh session when the folder has nothing open at all.

Tab shortcuts act within the folder you are looking at, so closing the last tab in one folder does not drop you into another. Two folders with the same name stay separate, and so does the same folder mounted into two different sandboxes.

What a project is called

A sandbox's project is named after the folder it was mounted from, not the path it has inside the guest. Every sandbox mounts its project at a fixed guest path, so without this every sandbox would show the same meaningless workspace label in the sidebar, tabs and command palette — a sandbox on ~/repos/codev-hub reads codev-hub.

The real folder name is shown from the first moment rather than after a round trip through the sandbox's server, so a new sandbox does not flash workspace on the way. A name you set yourself always wins.

Restarting, without surprises

Applying a mount restarts the sandbox on macOS and Linux, and for those seconds the app holds still:

• Open tabs wait, with a spinner, and come back on their own — they are not closed and reopened.
• Pinned and Recents stay empty beside "Your sandbox is not running yet" rather than switching to the local machine's sessions and back.
• The tab strip keeps the folder you were in instead of briefly widening to every folder of the sandbox.

A New session tab belonging to a restarting sandbox waits too. It used to quietly render the local machine's composer — the sidebar said Work, the screen was Code, and sending the prompt would have run it on your own machine.