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.
| Field | Type | Default | Description |
|---|---|---|---|
command | string | — | The command to run. |
cwd | string | sandbox default | Working directory. |
timeoutMs | number | 30s (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:
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):
| Area | Routes |
|---|---|
| Project | GET /api/project |
| Object types | GET /api/object-types, GET /api/object-types/:id |
| Objects | GET /api/objects, POST /api/objects/query (+ /count, /exists, /facets), GET /api/objects/:objectTypeId/:objectId |
| Telemetry | POST /api/telemetry/history, GET .../telemetry/:propertyId/history, .../latest |
| Actions | GET /api/actions, GET /api/actions/:actionId, POST /api/actions/:actionId, GET /api/action-runs/:runId |
| Files | GET /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:
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.
Related
- Sandboxes
- Authorization
- Objects and Actions — what the agent can query and request.