When granting an artificial intelligence agent access to an isolated environment (Sandbox), a fundamental question arises regarding how to organize the files the agent will work on. The Docker Sandbox platform (referred to as sbx) provides three main models for managing source code, each having a direct impact on the developer's workflow and interaction with the agent.
1. Shared Mounts
This option allows sharing the current workspace path from the host machine directly with the isolated environment. When running sbx run from the project folder, the folder is mounted to the same absolute path inside the environment. This model is ideal for close collaboration on a single task, as the developer can see changes in their local editor immediately, and local development servers can capture modifications via the hot reload feature.
Warning: Caution must be exercised regarding dependency conflicts; packages containing native binaries might work in the isolated Linux environment and fail on macOS or Windows, so it is recommended to standardize the runtime environment or separate dependency installation.
2. Git Worktrees
This option is suitable for executing multiple tasks simultaneously. It grants each task its own folder and branch, allowing each work tree to be linked in a separate isolated environment. The advantage here is complete task isolation, but a technical constraint remains: the .git file points to metadata outside the mounting scope, meaning operations like checking status (git status) or switching between branches must be performed from the host machine.
3. Clone Mode
In this mode, the sbx tool creates an independent copy of the code inside the isolated environment, while mounting the host code as read-only. This gives the agent full access to Git within the environment, making it completely independent in managing branches and commits. After work is completed, the developer can fetch the changes via a remote Git repository.
What Does This Change in the Developer's Workflow?
Choosing the appropriate method depends on the nature of the task and the extent of your desire for direct intervention:
- Close collaboration: Use shared mounts if you want to monitor the agent's work moment by moment.
- Independence: Use clone mode or fully isolated environments (Mountless) if you want to give the agent space to manage tasks without affecting your local work environment.
- Managing multiple projects: Workspace managers can be used to bundle multiple repositories into a single environment, making it easier for the agent to handle interconnected projects (such as a frontend and backend).
Remember that isolated environments that do not rely on mounting host files (Mountless) require manual port management to access development servers from your local browser, a practice that increases isolation security but adds some extra setup steps.