Isolation And Security
Trust boundaries for sessions, tools, storage, and scripts.
Little Harness: published on npm as little-harness@0.2.0-alpha.0 (2026-10-05). Sections labeled UNRELEASED describe source-only changes. Release status
Little Harness makes isolation the default behavior.
The first principle is simple: one session's files are not visible to another session unless the developer explicitly configured shared persistence.
Session Isolation
Each session receives its own workspace, artifacts, and trace. Parallel sessions do not mutate each other's working files.
Shared state only appears through:
- a Persistent Dir
- a host tool
- an export action
- a future policy-controlled shared memory feature
Tool Trust
Tool handlers run in the host app's trust boundary. The harness can trace and mediate tool calls, but it cannot make a malicious host tool safe.
Write tools should be named and described clearly:
save_report
create_ticket
update_crm_noteAvoid vague write tools such as finish, sync, or do_action.
Runtime Trust
Tier-0 — just-bash, bash emulated in JavaScript over a virtual filesystem — is a compatibility layer for trusted tool patterns, not an isolation boundary. Its commands never touch the real filesystem, processes, or sockets, so ordinary tool scripting is contained by construction; but that containment is a library's parser and virtual filesystem, not the operating system. Treat it as protection against mistakes, not against an adversary.
What follows from that:
- Model-authored code does not run in the host process by default.
localHost()defaults itssandboxoption to"auto": a turn stays in-process only whenruntime.pythonandruntime.javascriptare bothfalseand network is off. Every other turn runs insubprocessSandbox()."in-process"opts out of that rule and should be reserved for trusted, read-only tool turns. - The subprocess sandbox is the floor for anything beyond pure read tools. Its
worker starts with an empty environment (your API keys and tokens never reach it),
a parent-side SIGKILL watchdog and init deadline, and just-bash's
defense-in-depth layer, which
defenseInDepthForAdapterturns on only in the worker — in-process it would patch process-wide globals of your app. - Neither tier confines native code. Use an OS-level sandbox (container, VM, microVM) behind a custom sandbox for genuinely untrusted workloads.
The rest of the design still applies around either tier:
- network off by default
- explicit harness directories only
- host tools as explicit capabilities
- trace records for tool and file activity
- no arbitrary host path exposure by default
See Execution Environments for the modes and Execution Tiers for escalating commands Tier-0 cannot run.
App Policy
The app should still decide:
- which tools are available
- which users, teams, or request contexts may use them
- which Persistent Dirs are exposed
- whether export tools require approval
- how persistence failures are surfaced to users