Skip to main content
Genie works with the sandboxes your agents run code in, and with sandboxes of the workspace’s own, made through the API, the SDK or Genie.
Sandbox work is off until an administrator turns on GENIE_SANDBOXES_ENABLED for the organization. Until then Genie says it cannot help with sandboxes yet, and leaves an agent’s Sandbox tool alone.

​
An agent’s sandbox

  • Set it up. “Give Report Builder a sandbox with 2 execution slots that asks before writing files” changes the agent’s Sandbox tool on one card, each setting with its value before and after.
  • See what is in it. Genie lists the sandboxes the workspace has, each named by its agent, and reads the files in an agent’s sandbox without asking.
  • Run a command. The card names the agent and shows the command. The reply gives the output and the exit code; a command that fails is a result, not an error.
  • Reset it. The card names the agent and says every file in its sandbox is deleted. It asks every time. Turning the Sandbox tool off keeps the sandbox; only a reset or deleting the agent removes it.
  • Open its shell. Asked to, Genie opens the agent’s Actions section with the shell on its sandbox. Connecting stays yours.
An agent with the Sandbox tool on has no sandbox until it is first used.

​
A sandbox of the workspace’s own

Genie can create one, write files into it, run commands in it and delete it, each change on its own card. Cards name the sandbox by its label.

​
When a sandbox cannot start

When the deployment has no free execution slots, Genie says how many slots the sandbox needs and how many are free, and offers to try again later. The workspace’s limit of sandboxes of its own and a missing sandboxes:run permission are explained the same way. Running commands needs the sandboxes:run permission; resetting an agent’s sandbox needs permission to edit the workspace’s agents.