When multiple agents (or you and an agent) work in the same repo, you hit conflicting branches, half-written files, and serial bottlenecks. Sandboxes give each task its own isolated environment so you can run agents in parallel, let them work while you’re AFK, or hand off long-running tasks to a remote VM.Documentation Index
Fetch the complete documentation index at: https://docs.joggr.ai/llms.txt
Use this file to discover all available pages before exploring further.
What is a Sandbox
A sandbox is an isolated environment with its own branch, files, and execution context. You create one, Joggr sets up a separate space, and your main working tree and other sandboxes are unaffected. Each sandbox is independent, so there’s no stashing, branch juggling, or waiting for another agent to finish.Why Sandboxes
If an agent is working on your branch, you’re blocked until it finishes. And when agents run in your working tree, they can reach SSH keys, credentials, and other projects. Without isolation, parallel work is a liability and auto-approve mode is a security hole.
- Parallelism — each task gets its own environment. You keep working while agents run independently.
- Isolation — agents in your working tree can reach SSH keys, credentials, and other projects. Sandboxes scope what an agent can access.
- Automation — start an agent and walk away. Sandboxes give you confidence that a runaway agent can’t trash your host, leak secrets, or corrupt unrelated work.
Parallel Work
Run multiple agents simultaneously — a refactor in one sandbox, a feature in another, tests in a
third. No interference, no waiting.
Zero Context Switching
Detach and agents keep running in the background. Reattach anytime — no stashing, no remembering
which branch you were on.
Scoped Access
Agents only touch what they need. No access to your SSH keys, credentials, or other projects
unless you explicitly allow it.
Reproducible Environments
Consistent, clean environments for builds, tests, and reviews. No “works on my machine” — every
sandbox starts from a known state.
How It Works
The workflow is the same regardless of sandbox type (local worktrees, containers, or cloud VMs).Create
jog sandbox create provisions an isolated environment with its own branch and file tree.
Configured files (.env, caches, tool configs) are copied in automatically via the copy
option, then run commands execute to get the environment ready — pnpm install, pnpm build,
whatever your project needs. Finally, the command option launches your agent or shell. The
sandbox is ready to work the moment it’s created.Work
Run agents, write code, execute tests — everything is scoped to the sandbox. Your main working
tree and other sandboxes are unaffected.
Attach / Detach
Switch between sandboxes with
jog sandbox attach. When you detach, the sandbox keeps running
in the background — agents continue working while you move on to something else.Where Your Code Runs
Each sandbox type trades off speed for isolation. Local is fastest but shares your host. Containers add filesystem and network boundaries. Remote runs on a separate machine entirely.Local
Git worktrees on your machine. Fast and lightweight.
Container
OCI containers with full filesystem and network isolation.
Remote
Cloud VMs that run while your laptop sleeps.
Comparison
Not sure which to use? Here’s how they stack up.| Local | Container | Remote | |
|---|---|---|---|
| Isolation | Branch-level | Filesystem + network | Full machine |
| Speed | Instant | Seconds | Minutes |
| Requires | Git 2.5+ | Docker / Podman | — |
| Host access | Full | Scoped | None |
| Best for | Day-to-day dev | Untrusted agents, reproducible builds | Long-running tasks, team collab |