Feature deep dive
Jack ships a per-session Docker sandbox toggle. Flip it and the AI coding agent runs inside a container — your workspace mounted read-write, your auth credentials read-only, hooks and MCP staying on the host. Sandbox or don't, per session, no global setting needed. Same UI whether you are running Claude Code, OpenAI Codex or Google Gemini. Permissions still gate every tool call inside the container.
The sandbox is a kernel-level boundary around the agent process and everything it spawns. Inside the container the agent sees:
Outside that perimeter, the agent has nothing. No home dir, no other projects, no system files, no SSH keys you didn't mount.
Hooks and MCP servers stay on the host. That is a deliberate design decision. Your pre-commit hooks talk to local services, your MCP servers expose host-side tools, your shell aliases live in your home dir — sandboxing the agent should not break any of them.
The boundary is around the agent process, not around everything the agent might want to talk to. When the agent invokes a hook or calls an MCP tool, the call crosses the container boundary and runs on the host with the host's credentials and the host's network. The permission inbox still gates those crossings.
Different sessions deserve different trust levels. A session running an unfamiliar model on a refactor task you don't fully understand wants the container. A session running a model you trust on a tiny config edit wants the speed of running locally. Forcing one global setting for both is a worse default than letting the toggle live next to the session.
The same workspace can host one Claude Code session running locally and one OpenAI Codex session running inside a container, side by side, on the same files. Each picks its own answer.
Auth files are bind-mounted read-only into the container at the path the provider CLI expects. The container can read them to log in to the provider API; it cannot modify them. When the session ends, the mount goes away and nothing leaks.
For providers that use environment-variable credentials (e.g. OPENAI_API_KEY), Jack passes the variable into the container at start time. It is not baked into the image, it does not persist past session lifetime, and it is not visible to other sessions.
Container startup costs roughly the time it takes to start a fresh shell — under a second on a warm Docker daemon. After startup, the agent runs at native speed; the boundary is enforced by the kernel, not by an interpreter. Bind-mounted files have native I/O performance.
The first sandboxed session in a workspace has a slightly longer cold start (image pull or cache warm-up). Subsequent sessions reuse the cached image.
Jack works without Docker. The sandbox toggle is simply hidden when no Docker runtime is detected. Every other feature — workspaces, the permission inbox, handoffs, the git panel, the diff editor — runs identically. Sandboxing is an add-on for when you want it, not a hard requirement.
No. The Docker sandbox is optional. Jack works without Docker installed — the sandbox toggle is simply hidden when no Docker runtime is detected. All other features (workspaces, permission inbox, handoffs, git tooling) work regardless.
Yes. Sandboxing is a per-session toggle, not a global setting. The same workspace can host one Claude Code session running locally and one OpenAI Codex session running inside a container, side by side. Each session decides for itself.
No, by design. Hooks and MCP servers stay on the host. The sandbox isolates the agent's filesystem and command surface, not your local tooling. If your hooks talk to the host network or to local services, sandboxing the agent does not break them.
Writes attempted outside the mounted workspace fail at the container boundary. The agent cannot reach into your home dir, your other projects, or your system files. The workspace mount is the only writable surface.
Claude Code's process-level sandboxing on macOS (Seatbelt) and Codex's approval policy are still active when Jack runs them inside a container. Jack's Docker sandbox is an additional, coarser-grained boundary — kernel-level isolation rather than per-process. The two compose.
Jack ships a default image with sensible developer defaults. Per-workspace image overrides are on the roadmap; for now, the default image covers Node, Python, Git, common build tools and the bundled provider CLIs.
