How we isolate Linux terminals per candidate
Engineering · 6 min · June 19, 2026 · by Omar Farouk
A look at the per-candidate Docker sandboxing behind the Terminal engine — real shells, zero shared state.
The Terminal engine gives a candidate a real Linux shell — install packages, edit files, run services, break things. That's only safe because every session is its own throwaway world.
One container per attempt
When a candidate opens a terminal task, we spin up a dedicated Docker container from a lightweight base image, pre-loaded with the packages the author specified. It has no shared state with any other session and no route to internal services.
- Per-candidate container, torn down at submit
- Network-restricted — no lateral access
- CPU / memory / time caps per session
- Full session recorded for the reviewer
Fast to start, safe to end
Base images are pre-built and cached, so a shell is ready in a second or two instead of a cold `docker build` every time. On submit, the whole container is destroyed — nothing the candidate did can leak into the next attempt.
Graded on what they actually did
The reviewer sees the exact commands the candidate typed as a transcript, plus an optional session recording — so grading is based on the real work, not a guess.