Skip to main content

Documentation Index

Fetch the complete documentation index at: https://veryfront.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

A sandbox is an isolated runtime workspace for project operations that need a shell, files, or long-running command execution without sharing state with the main application process. Use sandboxes for code generation, repository inspection, file transformation, browser automation, document processing, and agent tools that need a temporary workspace.

Lifecycle

A sandbox session starts as a project-scoped runtime allocation, moves through provisioning, becomes running when its runtime is ready, and closes when the caller deletes it or the platform reclaims it.
StateMeaning
pendingVeryfront accepted the session request and queued runtime allocation.
provisioningThe runtime is starting and preparing the workspace.
runningThe runtime accepts commands, jobs, file operations, and terminal connections.
errorThe runtime failed to start or became unavailable.
deletingThe session is closing and no longer accepts new work.
Keep session IDs only when you need reconnect behavior. Close sessions when work finishes so runtime capacity returns to the pool.

Runtime status

Use runtime status to decide which actions to show. A running session can still be temporarily unready while the runtime starts services or recovers from a transient error. Check readiness before long commands, file operations, or terminal handoff. Show provisioning and error states inline so users know whether to wait, retry, or create a new session.

Terminal access

Terminal access opens an interactive shell inside the sandbox workspace. Use it for exploratory debugging, one-off inspection, or workflows where streamed command output is easier to follow than a buffered command result. Keep terminal access project-scoped and authenticated. Don’t expose sandbox endpoints or tokens to unauthenticated browser contexts.

Command execution

Synchronous command execution runs a shell command and returns buffered stdout, stderr, and exitCode. Use it for short commands where the caller can wait for the complete result. Use synchronous execution for:
  • Inspecting a directory or file
  • Running a formatter on a small set of files
  • Checking tool availability
  • Running a quick validation command
Set a timeout for commands that can hang. For long-running commands, use async jobs instead.

Async jobs

Async command jobs start work in the sandbox and return a job record that can be listed, inspected, and canceled later. Use jobs for commands that take longer than an interactive request budget or need durable progress tracking.
Job actionUse
StartQueue a long-running command in the sandbox runtime.
ListShow recent jobs for the selected session.
OutputRead captured stdout, stderr, and exit status.
CancelStop a running job when the work is no longer needed.
Refresh the job list after start and cancel actions so the UI reflects the current runtime state.

File access and directory browsing

Sandbox file access is rooted in the workspace. Paths resolve through the runtime path guard and cannot traverse outside the workspace. Use file operations for:
  • Listing workspace directories
  • Reading generated files
  • Writing input files before a command runs
  • Inspecting job output artifacts
Directory browsing returns each entry’s name, path, type, and file size when available. Use directory rows to open deeper paths, and file rows to read exact file content or reuse a path in write and command workflows.

Agent and tool use

Agents use sandboxes when they need a real filesystem, command-line tools, or external runtimes. A sandbox tool can create a session lazily, run commands, write files, inspect results, and close the session when the agent run ends. Prefer lazy session creation for agents that may not need runtime work on every turn. Pass project context so billing, isolation, and audit trails stay attached to the right project.

Security and isolation

Sandbox sessions are ephemeral and authenticated. Treat them as project runtime resources, not public compute endpoints.
  • Keep auth tokens server-side.
  • Scope sessions to the project that owns the work.
  • Reject path traversal and absolute paths that leave the workspace.
  • Close idle sessions when work completes.
  • Store only artifacts that the project needs after the session ends.

API surfaces

Next

  • Runtime: Find where sandboxes fit with jobs, tasks, workflows, and runs.
  • Code sandbox guide: Use the sandbox client from application code.
  • MCP: Expose sandbox operations to MCP clients.