Workbench

Workbench gives an agent a session for running Python or JavaScript and processing files. Choose the allowed tools and their exact versions, and optionally name the connections the session can use. Every tool call still checks current access and approval rules.

Personal sessions act as their owner. Business sessions bind one end user and optional group. These identities cannot be changed after creation. A descriptive agent label does not grant additional access.

Sessions and runs

Create a session in Workbench, review its tool allowlist and limits, then submit code. Runs are queued and serialized within the session. Keep the same idempotency key when retrying the same logical submission. An interrupted run may have an unknown outcome: do not blindly resubmit code that could have side effects.

Tool access goes through Arc0's governed execution path. Provider credentials are never placed in the code environment. SDK-local function bodies cannot run here. An approval requirement returns a pending receipt; code cannot approve itself.

Changing configuration creates a new immutable revision. Configuration cannot change while a run is queued or running. Restart replaces the compute generation and restores only the retained files you explicitly select. It does not restore Python variables, JavaScript state or arbitrary process memory.

Calling tools and saving output

Relative paths resolve inside the session workspace. Uploads are restored only when selected by artifact ID. Save generated files explicitly; Arc0 does not export every workspace file.

receipt = arc0.call("your_app.lookup", {"query": "1234"}, version="1", connection_alias="support")
# Inspect receipt.status; an approval requirement is not an execution result.
arc0.save("summary.txt", "Reviewed output")

const receipt = await arc0.call("your_app.lookup", { query: "1234" }, {
  version: "1", connectionAlias: "support",
});
arc0.save("summary.txt", "Reviewed output");

Only session-allowlisted tools and aliases work, and their current authorization is checked again. These helpers belong to the compute environment; the host SDK methods shown below manage sessions.

Retained files

Uploads and generated files have metadata and a seven-day retention deadline. File contents are encrypted outside the database. Downloads require current authorization; outputs derived from tools also retain their original access dependencies. Removing a tool from a later session configuration does not remove these checks from earlier outputs.

Closing or expiration ends compute access. Retained files and receipts remain readable by their original authorized caller until their retention deadline. You may download or delete retained files after closing, but cannot upload new files or run more code.

Initial limits are 8 MiB per file, 64 MiB and 100 files per session, and 256 MiB per organization. Compute is capped at one CPU, 256 MiB memory, 64 processes, 64 MiB workspace, 30 seconds per run, 1 MiB captured output and 25 governed tool calls per run. Lower session limits may apply.

Runtime boundary

The local runtime uses a dedicated Docker runner with a non-root user, read-only root filesystem, no container network, dropped capabilities and enforced resource limits. The runner has no access to provider credentials through the code environment.

This local implementation is not a claim of production isolation for hostile code. Hosted compute requires a separately verified hardened execution pool, private object storage and operational cleanup controls before deployment.

SDK example

Use an execution key. Bind endUserId when creating your SDK client for an Embedded end user; Direct keys already bind their owner. File uploads take bytes, and downloads return bytes.

const session = await arc0.createAgentSession({
  agent: "Report helper", tools: [], connections: [],
});
const file = await arc0.uploadSessionArtifact(session.id, {
  name: "input.txt", bytes: new TextEncoder().encode("hello"), mimeType: "text/plain",
});
const queued = await arc0.createSessionRun(session.id, {
  language: "python", code: 'print(open("input.txt").read().upper())',
  artifactIds: [file.id], idempotencyKey: "your-stable-run-key",
});
const result = await arc0.waitForSessionRun(session.id, queued.id);
console.log(result.stdout);
await arc0.closeAgentSession(session.id);
const retainedBytes = await arc0.downloadSessionArtifact(session.id, file.id);

session = arc0.create_agent_session(agent="Report helper", tools=[])
file = arc0.upload_session_artifact(session["id"], name="input.txt", data=b"hello")
queued = arc0.create_session_run(
    session["id"], language="python", code='print(open("input.txt").read().upper())',
    artifact_ids=[file["id"]], idempotency_key="your-stable-run-key",
)
result = arc0.wait_for_session_run(session["id"], queued["id"])
print(result["stdout"])
arc0.close_agent_session(session["id"])
retained_bytes = arc0.download_session_artifact(session["id"], file["id"])

Polling only reads the run receipt. It returns terminal failures, timeouts and unknown outcomes without resubmitting code. Use configureAgentSession, restartAgentSession, and listSessionArtifacts to manage existing sessions; Python exposes the equivalent snake_case methods.

MCP access

When compute is configured, the Arc0 MCP endpoint also exposes manage_sessions, run_code, get_run and manage_files. They use the same session ownership and authorization checks as REST and the SDKs.

MCP output and file reads are paginated to avoid flooding an agent's context. get_run returns one selected stream (stdout by default, or stderr) with a UTF-8 byte budget of 16 KiB by default, up to 64 KiB per page. Its output contains {stream, text, offset, nextOffset, totalBytes}; use the returned nextOffset for the next page. Offsets inside a UTF-8 character are rejected. Metadata includes stdoutBytes and stderrBytes. manage_files returns file contents in 48 KiB pages encoded as base64. MCP uploads are capped at 192 KiB; use the SDK or Workbench for files up to the regular 8 MiB limit. Discovery metadata never includes file contents.