Runtime

A Runtime is the recipe.

A list saying which Provider handles each part of one specific deployment.

A Provider is a translator that knows one tool. A Runtime is the list of which translators to use together — for this deployment, on this kind of machine, in this ecosystem.

At a glance


Composed of	one Provider per part of the deployment (harness / OS sandbox / interpreter / LLM gateway / MCP broker)
Authored by	the operator (picks Providers when creating a Sandbox-spec)
Used by	the host runtime to know which Providers to invoke for a given Sandbox
Examples	`claude-code-laptop`, `cursor-laptop`, `langchain-react-canonical`, `openai-assistants`

What it looks like, concretely

For a deployment of Claude Code on a developer laptop, the Runtime claude-code-laptop is this list:

Part of the deployment	Provider that handles it
The Claude Code agent's tool permissions	`claude-code` (writes the agent's settings.json)
The OS-level sandbox around the agent process	`nono` (applies macOS/Linux process isolation)
Python code the agent writes	`monty` (constrains imports, memory, network)
LLM API calls	`anthropic-gateway` (routes through TapPass)
Tool calls (MCP traffic)	`mcp-broker` (routes through TapPass)

That bundle = the claude-code-laptop Runtime. Operator picks Providers; the Sandbox actually runs the recipe.

Why we need many Runtimes

Same Policy, different ecosystems → different recipes:

Runtime	Used for	What's in the recipe
`claude-code-laptop`	dev laptops running Claude Code	claude-code + nono + monty + Anthropic gateway + MCP broker
`claude-code-server`	CI / build hosts	claude-code + OpenShell + monty + Anthropic gateway + MCP broker
`cursor-laptop`	Cursor on dev laptops	cursor + nono + (Cursor has no codemode hook) + OpenAI gateway
`langchain-react-canonical`	custom Python via `tappass-agent` SDK	sdk-direct + OpenShell + monty + multi-provider gateway + MCP broker
`openai-assistants`	OpenAI Assistants API consumers	(gateway only — Assistants run on OpenAI's servers)

A customer with a heterogeneous stack picks multiple Runtimes — one per surface — and applies the same Policy to all of them. The Compatibility Matrix shows what each Runtime delivers.

One Runtime → many Sandboxes (every dev's laptop running Claude Code = its own Sandbox, all under the same claude-code-laptop Runtime).

What it's made of

Runtime "claude-code-laptop-strict"
├── harness    → claude-code provider              (managed settings.json + PreToolUse hooks)
├── kernel     → nono provider                     (sandbox-exec on macOS / Landlock on Linux)
├── interpreter → monty provider                   (Python codemode containment)
├── llm gateway → llm-gateway-anthropic provider   (env-var redirection)
├── mcp broker  → mcp-broker provider              (every MCP connection through TapPass)
└── update model: per-ring (claude-code: file rewrite; nono: restart; monty: re-import; gateway: live)

Runtime IDs are operator-named (claude-code-laptop-strict, librechat-internal-server, cursor-team-eng, …). They are reusable across many sandboxes — every sandbox-spec selects a runtime.

Example runtimes

Runtime id	Harness	Kernel	Interpreter	Gateway	MCP	Use case
`claude-code-laptop`	claude-code	nono / sandbox-exec	monty	llm-gateway-anthropic	mcp-broker	Dev laptops running Claude Code
`claude-code-server`	claude-code	openshell	monty	llm-gateway-anthropic	mcp-broker	CI / build agents running Claude Code
`cursor-laptop`	cursor	nono	— (no codemode)	llm-gateway-openai	partial	Dev laptops running Cursor
`librechat-server`	librechat plugin	openshell / k8s	monty	llm-gateway-multi	mcp-broker	Self-hosted LibreChat
`element-bot`	element-bot SDK	openshell / k8s	—	llm-gateway-multi	mcp-broker	Element / Matrix self-hosted bot
`openai-direct-no-sandbox`	sdk-direct	—	—	llm-gateway-openai	—	Custom code with gateway-only governance
`langchain-react-canonical`	sdk-direct	openshell	monty	llm-gateway-multi	mcp-broker	The reference custom-code path; full 5-position depth
`collibra-steward-laptop`	claude-code OR sdk-direct	nono	monty	llm-gateway-multi	mcp-broker	The demo runtime

A customer with a heterogeneous estate (Claude Code on laptops, LibreChat on servers, custom Python in CI) defines multiple runtimes, applies the same policy to each via different runtime selections, and gets governance depth appropriate to each ecosystem.

Lifecycle

[author]      Operator picks providers per ring + gateway config
              tappass runtime create --name claude-code-laptop \
                  --harness claude-code --kernel nono --interpreter monty \
                  --llm-gateway anthropic
   ↓
[validate]    Compiler checks provider compatibility + manifest coverage
              (which Compiled Policy fields are unenforced under this runtime?)
   ↓
[publish]     Runtime saved to per-org runtime registry
   ↓
[bind]        Sandbox-spec references a runtime id
              tappass sandbox-spec create --runtime claude-code-laptop --policy …
   ↓
[provision]   Sandbox emit-bootstrap → tappass-host init/start → providers run
   ↓ at sandbox start, host invokes each provider's apply path:
   ↓   harness provider writes its target config
   ↓   kernel provider creates sandbox + applies rules
   ↓   interpreter provider configures executor
   ↓   gateway provider sets env vars / endpoints
   ↓
[run]         Agent runs in the instantiated runtime
              On manifest change: each provider re-applies via its update model
   ↓
[evolve]      Provider versions bump → runtime pinning lets operators control upgrade

The Compiled Policy coverage report (per runtime)

A runtime exposes which Compiled Policy aspects it can fully / partially / not enforce:

Runtime "cursor-laptop":
  Compiled Policy aspect      Coverage
  ─────────────────────────────────────
  network              ✓ via cursor (limited) + llm-gateway-openai
  filesystem           ✗ not supported by cursor + nono not selected
  tools                partial (cursor harness allow/deny)
  interpreter          ✗ no interpreter provider selected
  budget               ✓ via llm-gateway-openai
  compliance_tags      ✓ recorded in audit

This report is the buyer-facing answer to "what governance do I get with my stack?". A buyer reading "Compiled Policy coverage: cursor-laptop covers 3/6 aspects" knows exactly what's enforceable. Switching to claude-code-laptop lifts coverage to 5/6 (everything except possibly kernel-level egress on macOS, depending on nono features).

Engines that operate on Runtimes

Engine	What it does	Status
Runtime registry	Per-org list of authored runtimes	concept
Compiler — provider routing	Composes selected providers; runs each on the manifest	concept (extends policy compiler)
Compatibility checker	Validates provider combinations + reports manifest coverage gaps	concept
Runtime instantiator (host-side)	At sandbox start, invokes each provider's apply path	concept (within host-runtime-cli)

Surfaces

Persona	Surface	What you do
Operator	`tappass runtime create / list / show <id>`	author and inspect runtimes
Operator	`tappass runtime coverage <id>`	manifest coverage report (which aspects this runtime fully enforces vs. not)
Operator	`tappass sandbox-spec create --runtime <id>`	bind a sandbox-spec to a runtime
Operator (visual)	Onboarding wizard	pick a runtime from a curated set or compose your own
Buyer / partner	Coverage matrix per ecosystem	answer "what governance do I get?" per ecosystem

composed of ← Provider (one per ring + cross-cutting layers)
bound to → Sandbox (each sandbox runs in exactly one runtime)
referenced by → Sandbox-spec (each spec selects a runtime)
applies → Compiled Policy (Keyring) (the canonical IR each provider consumes)

Authoritative docs

Topic	File
Strategic frame	TapPass Strategy Memo v3 §06 (rings & targets) + §08 (mapping agent surfaces to architecture)
Provider taxonomy	provider card
Sandbox lifecycle	sandbox card

Status snapshot

Aspect	Status
Runtime as first-class concept	NEW (this card)
Runtime registry	concept (Q3 2026)
Compatibility checker + coverage report	concept (Q3 2026)
Curated v1 runtimes (claude-code-laptop, librechat-server, …)	concept (Q3-Q4 2026)
Custom runtime authoring (full provider selection)	concept (after curated v1)

Common confusions

Runtime ≠ Sandbox. Runtime is the recipe; Sandbox is the running instance using that recipe. One runtime → many sandboxes.
Runtime ≠ Provider. Provider is one component (the Claude Code provider, the OpenShell provider). Runtime is the assembly of providers.
Runtime ≠ Ecosystem. "Claude Code" is a target (one harness provider). "Claude Code on laptop with nono kernel and monty interpreter" is a runtime (a specific composition). Different runtimes can use the same harness provider with different kernel + interpreter providers.
Runtime is operator-authored, not vendor-supplied. TapPass ships curated default runtimes for common combinations, but the operator can compose any provider combination they want (subject to compatibility checks).

Runtime

Runtime

At a glance

What it looks like, concretely

Why we need many Runtimes

What it's made of

Example runtimes

Lifecycle

The Compiled Policy coverage report (per runtime)

Engines that operate on Runtimes

Surfaces

Related concepts

Authoritative docs

Status snapshot

Common confusions