Aller au contenu

Harness boundaries

conversation/ is the shared durable-Session scheduler: one conversation per activation, serial turns, shared admission, recovery and exact interrupt settlement. Once the Node is stopping, the scheduler claims no new turn, even when the claim waits for the database lock: the queued turn stays queued for the next start. A runtime process that ends then (processExit on its error) did not fail: its activation stays recoverable, and the ledger and the stream report no failure for its in-flight turn (the stream closes it as interrupted), and the next start reconciles the turn as outcome-unknown, as for a crash. Known limit: Codex reports some host and I/O failures as runtime_exited, so such a failure during a stop is also treated as an exit; it applies only while the Node stops, and a real fault shows again on the next start. A vendor error, a refusal, or any other failure still fails the turn and the Session. Every runtime adapter implements its SessionConversation port; vendor executors register through ExecutorRuntimes.

pi-rpc/ is the Darwin Session driver: Node owns the Session and pilots official Pi --mode rpc under cooperative_pi_rpc_conversation. That path does not claim hard containment and does not modify the Pi CLI. pi-managed/ remains the hard-containment worker (Windows Job Object). It validates the packaged worker protocol, acquires one exact node-private provider lease, hydrates it under revision/fence checks, bounds process lifetime below lease expiry, and releases it after positive process-cleanup proof. Uncertain cleanup preserves the lease until expiry reconciliation.

codex/ keeps the independently registered Codex runtime probe and adds the Codex CLI vendor executor (source candidate). An executor Session launches codex app-server through the codex-session owner, which the integration authorization admits only for the exact human-approved executable. Each launch sets CODEX_HOME from the Session's Connection (or leaves it unset for a system-default account), a private TMPDIR, and Maia's maia-read permission profile through -c overrides: the worktree is readable, other folders, sibling account roots, credentials, writes and network are denied. A coding Session runs maia-write instead: the same profile with its own worktree writable, plus macOS's OpenSSL configuration, a Node-owned Git configuration and, when its repository's Git configuration holds no credential, the Git metadata status, diff and log need, to read, and a Session-only cache folder to write (D-101); its questions wait for a person and Codex refuses its escalations. Other vendor approval requests are declined, user MCP servers and out-of-profile vendor features are disabled by name, usage-limit reports are journaled on the Connection, and a restart resumes the recorded thread.

claude/ adds the Claude Code vendor executor (source candidate). The Agent SDK runs inside the Node as a protocol client in streaming-input mode; its spawnClaudeCodeProcess receives a bridge, and Maia launches the human-approved claude copy through the claude-code-session owner after checking the requested executable, working directory and flags. Claude gets a fixed environment (no ambient API key, CLAUDE_CONFIG_DIR from a Maia-managed Connection, private TMPDIR, auto-update off), no filesystem settings or external MCP, the Read, Grep and Glob tools, and a PreToolUse guard that keeps every path inside the worktree. A coding Session also gets Edit, Write and NotebookEdit under the same guard (no .git, no ~, real paths through the nearest existing folder) and Bash in Claude's sandbox, which writes only the worktree and private temp and reads neither the home folder, the Node's state nor sibling worktrees. It also gets Maia's maia-worker Skill as a launch plugin (--plugin-dir-no-mcp, the one plugin the spawn check admits) and the Skill tool limited to it. A rejected subscription window is journaled on the Connection, and a restart resumes the recorded Claude session id. claude/items.ts maps the Agent SDK's messages onto the Session item stream, as codex/items.ts does for app-server notifications. conversation/ runs an activation's prepare step (a coding Session's Project setup and worker Skills) inside the activation fiber before the runtime opens, and opens the runtime with the Skills it injected. Both executors feed session observe with native activity and process usage through conversation/observation.ts.

worker-mcp/ resolves the installed CLI for coding Sessions and defines the reserved maia_worker server. Codex injects a required MCP server with environment variable names and an exact tool allow-list. Claude uses the SDK's strict MCP config and exact guarded tool names. The vendor launches maia mcp --worker outside the tool sandbox with the Session's own credential; sandbox limits stay unchanged. Missing credentials or unsafe executable paths refuse launch, and Node authenticates every operation. See worker MCP at launch.

sandbox-host/ reads, without running anything, what a Linux host gives the vendors' own sandboxes (bwrap and socat on the Node's PATH, the userns sysctl and Ubuntu's bwrap AppArmor profiles). Session creation refuses an executor whose sandbox the host cannot run, and node status reports the same facts.

installed/ provides the filesystem-only inventory and executable resolution for those operations.

Historical database migrations and compatibility decoders remain so preserved runtime identities, events, receipts, and rows stay readable and fail closed for current mutation.

In this section

  • Claude

    The pages of the Maia OS documentation under Claude.

  • Installed harness detection

    This directory detects only the explicit codex, cursor-agent, grok, vibe / mistral-vibe, and pi executable names.

  • Worker MCP launch

    Resolves the installed maia command from the Node's absolute PATH, outside the coding Session's writable directories. It follows links one hop at a time and checks every directory on the way.

Imported from Maia OS docs at a2175bb