Extension Isolation

Extension Isolation

The explicit v1 decision about how trusted extensions run: in-process, without a sandbox. The page names the choice, enumerates what it buys and what it costs, and lists plausible future models.

---

The invariant

v1 runs every loaded extension in the host process with full runtime capabilities. There is no sandbox.

CI enforces this: a code-level no-sandbox-claim assertion scans the codebase for prose, comments, or messages implying v1 extensions are sandboxed and fails the build on any hit.

An extension that passes Validation and trust checks may:

• Access any file the user can.
• Reach the network.
• Read env values through the Env Provider (scoped by declared name).
• Allocate memory, spawn subprocesses, and block the event loop.
• See the session manifest, the event bus (per subscription), and the command bus.

Isolation is not a runtime control in v1. The controls that are:

• Project Trust — consent gate for loading.
• Validation Pipeline — shape, version, schema checks.
• LLM Context Isolation — secrets don't reach the model by default.
• Security Modes — tool-call gating (work plane only).

---

Why v1 chose no isolation

flowchart LR
    Goal[small<br/>plugin-host kernel] --> Choice["v1: in-process,<br/>trust-gated"]
    Choice --> T1[+ low latency<br/>between extensions]
    Choice --> T2[+ simple contracts<br/>no IPC shape]
    Choice --> T3[+ shared memory<br/>for context assembly]
    Choice --> R1[- bad extension<br/>crashes process]
    Choice --> R2[- bad extension<br/>reads other ext memory]
    Choice --> R3[- block event loop<br/>affects everyone]

Loading

The kernel exists to be small. An in-process model needs no serialization boundary, no IPC scheme, no lifecycle replication across processes. The tradeoff is that every trusted extension is as privileged as the user running the CLI.

This is load-bearing for the trust story — the trust prompt is the decision, not a safety net.

---

Consequences a reader must internalize

Concern	v1 posture
A bad extension crashes the session	Yes. The process dies; resume via Session Store.
A bad extension reads another extension's state	Possible. State slots are not memory-protected.
A bad hook blocks the event loop	Possible. Concurrency-and-Cancellation documents timeouts, not hard preemption.
A bad extension reaches the network	Possible. Network egress is not gated in v1 except via tool-call approval paths.
A bad extension reads secrets	Constrained by env name scoping, not by memory isolation.
A bad extension exfiltrates session content	Possible. Audit logs record reads; no runtime block.

The mitigations are review (global tier is install-time consent) and first-run prompt (project tier is runtime consent). See Project Trust.

---

Future models (not v1)

Enumerated so the wiki records the direction the architecture can move without re-litigating:

Model	What it would add	Tradeoffs
Worker-per-extension	Separate thread / worker context per extension	Prevents event-loop blocking; still shares process memory in most runtimes.
Out-of-process for project scope	Project-tier extensions in a child process	Process boundary; cross-process trust primitives still needed.
Capability-scoped host API	The host API surface reduced per extension contract	Orthogonal to isolation; moves the boundary from "trusted/untrusted" to "trusted for what."
Signed manifests + pinning	Cryptographic consent to specific binary versions	Installer-level, not runtime; pairs with Extension Integrity.
WASI-based sandbox	Wasm module per extension with restricted syscalls	Re-shapes every category contract around serializable data.

v1 picks none of these. Each is a conscious future investment.

---

What the wiki may not imply

Per CLAUDE.md rule 2 and the "Never" list:

• Do not imply the v1 extension host is sandboxed.
• Do not assume a project-scope extension is less privileged at runtime than a bundled one.
• Do not treat the Host API surface as a capability boundary — it is an ergonomic API, not a permission boundary in v1.

Pages that cover trust, secrets, approvals, or sandboxing propagate the "v1 is in-process" invariant where a reader might land cold. The dedicated Sandboxing page states explicitly that v1 has no sandbox, extensions run in the same Node process as core, and any sandbox design is post-v1 only.

---

Operational guidance (until isolation exists)

• Run yolo mode only in a container. See Sandboxing and Security Modes.
• Review project .stud/ before granting trust.
• Avoid pinning project-scope env values that resolve to real secrets — they are committable.
• Treat MCP servers in mcp.json as executables being trusted. See MCP Trust.
• Prefer OS env vars over settings.json.env for sensitive values. See Secrets Hygiene.

---

Related pages

• Trust Model
• Project Trust
• Extension Integrity
• Sandboxing
• Security Modes
• Secrets Hygiene
• MCP Trust