sbx<\/code> supports both. The way you organize the checkout can change as you ask the agent to take on more of the work.<\/p>\nMounting a repository from your host<\/h2>\n
Sharing a checkout puts the agent in the working tree you already use. Run sbx run<\/code> from your project directory, and it mounts that directory at the same absolute path inside the sandbox:<\/p>\n\n\n$ cd ~\/my-project\n$ sbx run claude\n<\/pre>\n<\/div>\nOpen a file in your local editor while the agent works on it, and you\u2019ll see changes as they happen. Git works from either side, so you choose whether you want to let the agent make commits or you do it yourself. Development servers on your host can pick up the edits through hot reload, using the runtime and dependencies installed on your host.<\/p>\n
This fits close collaboration on one task. The coordination cost comes from sharing that working tree: switching branches changes the files the agent sees, and your edits become part of its ongoing work. If you want to switch to something unrelated while the agent continues, you\u2019ll need another checkout.<\/p>\n
[!NOTE]<\/strong> Dependencies written into the shared checkout are shared too. Packages with native binaries, such as esbuild<\/a>, may work in the Linux sandbox and fail on a macOS or Windows host. Reinstalling on the host can reverse the problem. Keep separate dependency installations, or run the app consistently in one environment.<\/p>\nGive each task a separate working tree<\/h2>\n
Git worktrees give each task a directory and branch. You can mount each worktree in its own sandbox, while your original checkout remains available for other work. The agent\u2019s edits appear in the worktree. You can inspect either with your local editor and development tools. Each task also gets its own running environment, with tools to prepare and a sandbox and worktree to clean up afterward.<\/p>\n
\n ![\"image3](\"https:\/\/www.docker.com\/app\/uploads\/2026\/10\/image3-2.png\" "\\"-")
\n <\/div>\nThere is a Git limitation with mounting only a linked worktree. Its .git<\/code> file points to metadata outside the mount, which the agent can\u2019t reach. It can edit files, but checking status, branching, and committing have to happen on the host. The future of software development still needs you to run git status<\/code>.<\/p>\nsbx supports a clone mode<\/a> that gives the agent a separate checkout with Git available inside the sandbox. You keep your local project, but sbx<\/code> mounts the host source as read-only and creates an independent clone for the agent. Its branch changes and dependency installations stay in its checkout.<\/p>\n\n ![\"image2](\"https:\/\/www.docker.com\/app\/uploads\/2026\/10\/image2-2.png\" "\\"-")
\n <\/div>\nBringing the result back becomes a handoff. While the sandbox is running, you can fetch committed branches through the Git remote sbx<\/code> adds on your host. Or the agent can push to the repository\u2019s remote and you can retrieve the branch through your usual Git workflow. Your local editor and development server see the changes after you bring them into your checkout.<\/p>\nKeep the project inside the sandbox<\/h2>\n
A mountless sandbox has no host workspace directory attached. Clone the repository inside it, and the sandbox holds the checkout and its development environment. Your host copy of the project shares no connection with the sandbox checkout.<\/p>\n
\n ![\"image1](\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" "\\"-")
\n <\/div>\nThis workflow resembles working on a remote development machine. Agents connect to the project environment, and you can open a shell with sbx exec<\/code> or connect an editor to the sandbox over SSH. Changes and dependency installations stay separate from your host. To bring work back, you push a branch to the Git remote.<\/p>\nOne sandbox per project can be a useful mental model here. The project and its tools persist across agent sessions and sandbox restarts. An agent can create worktrees per feature it\u2019s working on, push branches, and create pull requests for review. Starting another task doesn\u2019t require you to prepare another host worktree and sandbox, and the agent has Git access in each working directory. Clone mode supports this internal-worktree approach too.<\/p>\n
Those tasks share tools and services, so running servers or changing the environment still needs coordination. Separate sandboxes are useful when tasks need independent environments as well as separate files. Branches alone don\u2019t isolate simultaneous edits in one working directory.<\/p>\n
That independence adds some distance when you want to try the result. Your usual local editor isn\u2019t looking at these files, and a development server running inside the sandbox needs a published port to reach it from your browser.<\/p>\n
For a web app preview, ask the agent:<\/p>\n
Start the development server on port 8080, bound to 0.0.0.0.<\/code><\/p>\nThen publish the port from another terminal on the host:<\/p>\n
\n\n$ sbx ports my-sandbox --publish 8080:8080\n\n<\/pre>\n<\/div>\nOpen http:\/\/localhost:8080<\/code> in your browser. It\u2019s possible to work interactively this way, but there\u2019s more ceremony than opening a project already on your filesystem.<\/p>\nAn environment file can make setup repeatable, selecting tools and cloning the repository at creation with something like the community github-clone kit<\/a>. Recreating the sandbox then gives you a fresh environment. Push or copy out work you want to retain first: removing a sandbox deletes files held only there.<\/p>\nChoose the repositories for the job<\/h2>\n
An API change might need a corresponding frontend change, or another repository might provide useful reference material. You can mount several directories into one sandbox, with read-only access for reference repositories. Local editing and previews remain available, but each writable checkout needs branch and change coordination. Task-specific checkouts also leave directories to clean up afterward.<\/p>\n
![\"image1](\"https:\/\/www.docker.com\/app\/uploads\/2026\/10\/image1-2.png\" "\\"-")
\n <\/div>\n