Docs

Tools and gateway

Every agent run gets two ways to do real work: a built-in bash tool that runs in a sandbox, and scoped access to your project's own objects, actions, and telemetry.

The bash tool

The bash tool runs a command (as bash -lc) inside a per-run sandbox that the worker provisions for the turn and destroys when it ends.

FieldTypeDefaultDescription
commandstringThe command to run.
cwdstringsandbox defaultWorking directory.
timeoutMsnumber30s (max 120s)Per-command timeout.

It returns the command result with stdoutTruncated / stderrTruncated flags; output is capped so a runaway command can't flood the turn. The sandbox boots concurrently with the turn, so if the model never calls bash the boot cost never lands on the user.

A sandbox is required

The bash tool always runs in a sandbox, so the agent-worker won't start without a factory:

TS
import { createSixb } from "@sixb/core"
import { SmolvmSandboxFactory } from "@sixb/sandboxes-smolvm"

export const sixb = createSixb({
  id: "acme-corp",
  // ...
  sandboxes: new SmolvmSandboxFactory(),
})

See Sandboxes for factory options and isolation.

Reaching your data

Inside the sandbox, the run gets a base URL and credentials in its environment to call a scoped slice of your HTTP API — typically with curl from bash. So an agent works against live project data, not a snapshot. These routes are allowed (everything else returns 403):

AreaRoutes
ProjectGET /api/project
Object typesGET /api/object-types, GET /api/object-types/:id
ObjectsGET /api/objects, POST /api/objects/query (+ /count, /exists, /facets), GET /api/objects/:objectTypeId/:objectId
TelemetryPOST /api/telemetry/history, GET .../telemetry/:propertyId/history, .../latest
ActionsGET /api/actions, GET /api/actions/:actionId, POST /api/actions/:actionId, GET /api/action-runs/:runId
FilesGET /api/objects/:objectTypeId/:objectId/files/content, GET /api/action-runs/:runId/files/content, GET /api/agent-threads/:threadId/messages/:messageId/files/content

Requests run under the agent's execution identity, so the agent can only see and act on what its groups allow — the same checks as any other caller, and only while the run is active.

Agent Skills in the sandbox

Every run also gets Agent Skills under $SIXB_SKILLS_DIR. Sixb installs built-in API skills such as sixb-query, sixb-telemetry, and sixb-actions, then adds project skills from skills/<name>/SKILL.md when that folder exists.

A project skill follows the Agent Skills folder format:

TXT
skills/acme-writing-style/
├── SKILL.md
└── references/
    └── examples.md

SKILL.md starts with name and description frontmatter. Only those metadata fields are listed in the model's always-on catalog; the agent reads the full SKILL.md and any referenced files from $SIXB_SKILLS_DIR/<name> only when the task matches. Use skills for company standards, examples, templates, and multi-step procedures that should not live in every agent's base prompt.

Search docs

Search the documentation