Book a Demo Talk to Sales

Sudo’s sandbox

A sandbox per chat, with your workspace as its files.

Sudo works in a shell with no disk, no process and no network. Your configuration is its filesystem. Every edit stays in the session until a person approves it.

Build Your OwnMeet Sudo

Runs Bash and Python, in process Reaches Only what is mounted Writes A session overlay Applies After a person approves

How it works

Sudo works in files. You read the diff.

Your configuration already exports as plain files. Studio hands those files to Sudo as a filesystem. He reads, edits and builds them with ordinary shell commands, and nothing leaves the session until you approve it.

Sudo’s shell · example session
 cd /workspace/code/endpoints lspart-lookup.cs  supplier-risk.cs grep -n "Take(" supplier-risk.cs14:    .Take(20) sed -i 's/Take(20)/Take(50)/' supplier-risk.cs statusM  code/endpoints/supplier-risk.cs 1 file changed. Run `build` to check it, then `commit -m "..."`. buildok    code/endpoints/supplier-risk.cs 1 of 1 file builds. commit -m "Return 50 suppliers, not 20"M  code/endpoints/supplier-risk.cs 1 file is waiting for the admin to review and approve.Nothing has been applied to the workspace.
  • /workspaceEdits are staged Your configuration, as the export writes it
  • /frontendApplied as a git commit Your front end, as source
  • /sdkRead only The C# surface and the UI library
  • /referenceRead only One well formed example per surface
  • /procRead only Live runtime state, read fresh
  • /artifactsNot staged Documents Sudo writes for you to open
  • /agentsAgents write here What each delegated agent wrote
  • /tmpScratch Scratch, in memory
  1. 01 Read
  2. 02 Edit
  3. 03 Build
  4. 04 Stage
  5. 05 You approve

The overlay

Your workspace underneath. Sudo’s edits on top.

The session stores only what Sudo changed. Everything else is read from the live workspace every time, so he works on the workspace as it is now, not on a copy that went stale.

  1. 01

    Sudo edits a file

    His change goes into the session, which keeps only what he wrote or deleted, and the version of the file he started from.

  2. 02

    Someone saves it in the admin pages

    The live workspace is read again before every command, so the next one sees it. The file is marked C: two edits to one file.

  3. 03

    pull merges both

    Sudo reads what changed, merges it into his copy, and starts from the new version. Where the two overlap, markers stay until he resolves them.

  4. 04

    commit stages, you approve

    The commit is a snapshot of the diff. Before it applies, Studio checks again that nothing moved. If something did, nothing is applied.

Agents

Sudo hands the bulky work to agents.

Reading a large surface or drafting one file per surface takes many commands. Sudo can send an agent to do it in these same files while he answers you. It is not worth it for two commands, and he does not use it for those.

  1. 01

    Sudo dispatches agents

    One call per piece of bulky, separable work, with background: true. Each answers at once with a run id, and Sudo carries on.

  2. 02

    Each reads everything, writes one directory

    An agent sees the same files Sudo sees, his uncommitted edits included. It can write only under its own /agents folder.

  3. 03

    Each ends with a report

    When a run finishes, Sudo gets a message only he reads, then reads the answer. Several can run at once.

  4. 04

    Sudo merges and stages one commit

    An agent cannot commit, publish or run anything. Sudo reads the drafts, keeps what is good and stages one change for you to approve.

What the sandbox will not do

Six limits that hold whatever Sudo is asked.

The sandbox has no ambient access. One exception, off until an administrator turns it on: a headless browser that reaches only the hosts they allow.

No process, no network

Every command is managed code inside the server. There is no fork and no exec. curl, wget, ssh and git are absent, not refusing.

No disk

The only paths are the mounts. A path under no mount does not exist, so there is no host file to read or write.

Data is read only

graph and query read as the administrator in the chat, skip node types that never leave the server, and cap an answer at 50 nodes. A cap says so instead of passing for the whole answer.

Build before commit

commit compiles every changed file against the workspace as the whole change leaves it. A file that fails blocks it, unless Sudo says --force and you approve it anyway.

One command at a time

A session runs one script at a time. Two callers wait in line, so their output never interleaves.

Parallel edits are refused

If someone changes a file after Sudo started on it, commit answers CONFLICT. --force does not pass it. Approval checks once more.

Build your own

The same sandbox, for your own data.

Sudo’s sandbox is not private to him. A sandbox is an AI tool in your workspace whose code returns an ISandbox. You say what the files are. Studio supplies the interpreter, the session, the limits and the history.

  1. 01

    Describe the files

    Mounts are lists of files your code builds from the graph: live, cached, writable, scratch, a fixed set, or lazy for a tree too big to name. Directories come from the file names.

  2. 02

    Add what a file cannot say

    Commands for answers that are not files. A query command over the node types you allow. A browser, only for the hosts you name. Artifacts, when the answer is a document.

  3. 03

    Give it to an assistant or an agent

    A sandbox is an AI tool: the same editor, access rules and versions as any other. Agents it delegates to are lent the session and write in one folder.

C# · an AI tool
public class CatalogueSandbox : ISandbox
{
    public string Description  => "The product catalogue.";
    public string FunctionName => "catalogue";

    public SandboxMount[] Mounts => new[]
    {
        SandboxMount.Live("/catalogue", "one file per product",
            scope => scope.Q().StartAt("Product").Take(500)
                .AsEnumerable()
                .Select(n => SandboxFile.Text(
                    n.UID + ".md", (string)n["Description"]))),

        SandboxMount.Scratch("/work", "notes"),
    };

    public SandboxQueryAccess Query
        => SandboxQueryAccess.For("Product").WithMaxNodes(200);
}

return new CatalogueSandbox();
MountYour code runsWritable
SandboxMount.CachedOnce per sessionNo
SandboxMount.LiveBefore every scriptNo
SandboxMount.WritableBefore every script, plus what the session wroteYes
SandboxMount.ScratchNever. It starts emptyYes
SandboxMount.FilesOnce, from a set you already haveNo
SandboxMount.LazyPer directory and per file, as the agent walks inNo
  • Time60 s per script, 300 s at most
  • Output256 KB per script, 4 MB at most
  • SessionKept between calls, unless you turn it off
  • NetworkNone, unless you name a host for the browser

Go further

Read how it is built, or build on it

Meet Sudo

The assistant

Who works in the sandbox, what his ears say, and where to find him.

Sudo

Inside Sudo

Technical paper

The sandbox, its limits and what an approval binds. For platform admins and security architects.

Read

Working with Sudo

Guide

What to ask, how a request becomes one diff, and how to review it.

Read

AI agents

Developers

Build the agents that work in a sandbox, on the graph, with the model you choose.

Agents

Documentation

docs.curiosity.ai

The sandbox tool, its mounts and its limits, with the full reference.

Docs

Your data. Your infrastructure.

Give an agent a sandbox. Keep the approval.

Book a Demo Talk to Sales