Your users

The design assumption that separates nativeharness from a terminal coding agent: the person the agent works for is not the person running the harness. Your users are many, they do not trust each other, and they must not be able to reach each other’s work.

Actors

An actor is a string: whatever identifies a principal in your system. A user id, a service account, a tenant. The harness never sees a password, a session cookie or an email; it sees an opaque name and enforces what that name may do.

Permissions

A workspace names who may work in it, where, and how:

permissions: [
  { actor: "user-42",  scope: "/",     mode: "commit"  },
  { actor: "user-7",   scope: "/docs", mode: "commit"  },
  { actor: "reviewer", scope: "/",     mode: "discard" },
]

Field	Effect
`actor`	who
`scope`	the subtree they may commit into; a command that writes outside it is not committed
`mode`	a ceiling: a `discard` actor cannot open a `commit` session

An actor not in the list cannot run a command at all. BashTool checks this on every execution, before a sandbox is even acquired.

Sessions

A session is one actor’s conversation in one workspace, in one mode:

const session = await store.createSession(workspaceId, { actor: "user-42", mode: "commit" });

Turns belong to sessions, and events are scoped to them, so a stream for one session never carries another’s. A session can be closed, and a new one started in the same workspace, with the files exactly where the last one left them.

Isolation

Each command runs in a sandbox hydrated from that workspace. There is no path from one sandbox to another workspace’s files, and the provider refuses a path that tries to leave the workspace rather than normalising it. The agent will not run a model’s commands on a provider that does not isolate.

Approvals

The approval policy reviews a command’s effects — the files it changed, the connectors it called — after the command ran in its sandbox and before anything is committed:

const policy: ApprovalPolicy = {
  review(effects, context) {
    if (effects.files.deleted.length > 20) return "ask";
    if (effects.connector_calls.some((c) => c.tool === "delete_repo")) return "deny";
    return "allow";
  },
};
new BashTool({ store, sandbox, events, approval: policy });

ask ends the turn needs_continuation and emits approval_required with the effects. Your UI shows them to a person; their decision comes back through agent.resume(), and it is recorded with who decided. The effects are staged at review time, so a decision can take a day and still commit cleanly. The policy’s job is your rules — a plan tier, a repository’s protection level, a customer’s settings. The harness enforces isolation and scope before the policy runs and does not ask it about them.

Questions

A model can call ask_user. That, too, ends the turn needs_continuation, with the questions in the event; the answers come back through resume. Nothing blocks waiting.

Per-user integrations

A connector is attached to a workspace with a reference to a credential that belongs to an actor. The credential never enters the sandbox: a per-command token does, and the gateway swaps it for the real credential on the way out. See Connectors.

What is yours

Authentication, user records, billing, quotas, which user gets which plan’s sandbox size — all yours, above the harness. The harness’s job is that once you have decided an actor may do something, that is exactly and only what they can do.

Getting started

How it works

Building your app

CLI

Operations

Actors

Permissions

Sessions

Isolation

Approvals

Questions

Per-user integrations

What is yours

​Actors

​Permissions

​Sessions

​Isolation

​Approvals

​Questions

​Per-user integrations

​What is yours

Actors

Permissions

Sessions

Isolation

Approvals

Questions

Per-user integrations

What is yours