Skip to content
Series
20 posts

Rivumi Architecture Notes

Follow one coding-agent task through Rivumi: from the TUI, disposable workspace, prompt, and two runtime lanes through tool authority, the state/event lifecycle, MCP, subagents, SDK/IDE integrations, and finally Cloudflare remote execution. Each article traces one data flow, failure boundary, and test surface.

A map of Rivumi: how one coding-agent task crosses workspaces, runtimes, tools, and events

Rivumi turns a coding-agent task into inspectable boundaries: native side effects cross Rivumi tools, permissions, and sandboxing, while external runtimes retain their own loops and tools before returning a patch for Rivumi audit. This article maps the planned 20-part series.

Rivumi's TUI and CLI: how a run becomes visible in the terminal

Rivumi's TUI and plain CLI are two interfaces over the same runtime paths. The CLI selects a presentation mode from TTY state and flags, runners emit events, and the TUI projects those events into thinking, tool, approval, verification, and terminal states. The screen distinguishes native and external runtimes without treating UI entry points as proof of backend maturity.

Rivumi's disposable workspace and run bundle: why the source repository stays untouched

Rivumi clones an exact Git commit into a detached-HEAD workspace inside the run directory before a runtime edits or verifies code. The source repository, execution workspace, and run artifacts therefore have distinct boundaries. This provides source isolation and an audit bundle, but it is not an OS sandbox.

Rivumi prompts, instruction precedence, and explicit memory: what the model actually sees

Rivumi resolves user and root-to-leaf project instructions before rendering named prompt sections for runtime, skills, workspace state, and the latest 20 explicit memories. The pipeline is traceable and reloadable, but it is not semantic memory and repository text does not become system authority.

Rivumi's provider-neutral native loop: from one model turn to a verified terminal state

Rivumi's native lane is controlled by AgentRunner: prepare a workspace, request a model turn, execute tool calls, append observations, and enter verification only when the model stops calling tools. Step, wall-time, repetition, token, and cancellation guards can terminate the run independently of the model. Protocol translation belongs to the next article.

Rivumi's ModelProvider multi-gateway: multiple protocols, one canonical contract

Rivumi collapses OpenAI-compatible, Responses, Anthropic, Gemini, Workers AI, scripted, and experimental Codex OAuth adapters into one `ModelProvider` contract. The Codex OAuth transport reads SSE but still reduces it inside the adapter into one canonical `ModelTurn`; AgentRunner does not consume token deltas.

Rivumi model roles, fallback, cache hints, and estimated cost

Rivumi uses a static model-role catalog and retries or falls back only after retryable provider errors. Cache data is a provider hint plus trace, while cost is a static-table estimate; neither is live routing intelligence or a bill.

Rivumi's ExternalCodingRunner: why Codex and Claude Code CLI are external runtimes, not ModelProviders

`ExternalCodingRunner` is Rivumi's second runtime lane. The external coding CLI owns its model loop and credentials; Rivumi hands off a task and disposable clone, then treats the returned patch as untrusted input and reruns path audit, verification, and the source invariant. This is a capability-bounded handoff, not another `ModelProvider`.

Rivumi's tool isolation: path allowlists, strict argv, process groups, and credential-free subprocesses

This article follows one Rivumi tool call through its mechanical execution boundary: `SafePathPolicy` for paths and symlink escape, fixed argv with `shell=False`, a sanitized subprocess environment, read-version hashes plus atomic replace for writes, and process-group cleanup at timeout. Permission policy, OS containment, and tool programs are reserved for later articles.

Rivumi permission layering: how dangerous commands become allow, ask, or deny

Rivumi applies a non-bypassable critical floor, evaluates user, organization, and project denies before any allows, and keeps execute operations policy-gated even in dangerous mode. This decides authority; it is not an OS sandbox.

Rivumi local OS sandboxes: fail-closed execution on macOS, bubblewrap, and Landlock

Rivumi can wrap configured local commands and verification in macOS sandbox-exec, Linux bubblewrap, or Landlock/seccomp. A required unavailable backend stops with exit 126 instead of running bare, but external CLIs, MCP/LSP processes, and the entire Rivumi process are outside this boundary.

Rivumi tool programs, transactions, and safe concurrency

Rivumi parallelizes calls only when they are read-only, concurrency-safe, and classified as READ. Tool programs provide bounded read-only repeat and branching, while transactions snapshot and restore possible workspace-file changes; external side effects are not rolled back.

Rivumi's state-first event journaling: recovering between manifest commits and JSONL appends

Rivumi maintains append-only `events.jsonl` and atomically replaced `session.json`, reconciling sequences before crash recovery. The same event contract now supports deterministic replay, canonical JSON replay, fork seeds at a selected sequence, and new workspaces without replaying old side effects; ambiguous `tool.started` or `verification.started` states still hard-fail.

Rivumi context pressure, compaction, and workspace reinjection

Near 85% context pressure, Rivumi has two distinct paths: the native loop can apply one bounded deterministic history fallback, while a conversation runtime with native compaction can compact after a completed turn. Both paths re-anchor the next request with workspace context.

Rivumi Native MCP: transport, authorization, and approval boundaries

Rivumi loads project MCP servers only through an explicit allowlist, projects stdio or Streamable HTTP capabilities into the existing ToolExecutor, and preserves hooks, approvals, timeouts, and cleanup.

Rivumi Skills, Blocking Hooks, and Plugin Packages

Rivumi treats skills as bounded repository-local guidance, hooks as opt-in host commands that can only deny, and local plugin manifests as packages for skills and hooks; their authority is deliberately different.

Rivumi Subagent Scheduling and Parent-owned Transactions

Rivumi normalizes each subagent dispatch into dependency waves of at most four nodes, runs read-only children concurrently in isolated workspaces, then makes the parent repeat hooks, approval, and transaction execution for any modification.

Embedding Rivumi: SDK, ConversationController, and the WebSocket Boundary

Rivumi exposes bounded-run and conversation contracts through a typed 0.x SDK facade. WebSocket attach wraps one prebuilt, controller-owned runtime session rather than providing conversation-ID resume or multi-client routing.

Rivumi IDE/LSP Context: Diagnostics, Open Files, and the VS Code Bridge

Rivumi normalizes up to 200 diagnostics and 32 visible files into bounded, repository-local, untrusted context. Its VS Code and managed-LSP paths supply signals rather than completion, rename, code actions, or full IDE RPC.

Rivumi remote execution on Cloudflare: Worker, Sandbox, Capability DO, and durable RunSession

Rivumi's old synchronous M6 path completed one real deployed coding run. It has since grown into an asynchronous control plane with RunSession, SSE, approvals, cancellation, and artifacts, but that newer path has not been live-revalidated. Audience-separated HMAC capabilities enter the Sandbox while provider credentials stay in the Worker; this is not production-traffic or SLO proof.