Runtime adapters
Jarvis uses runtime adapters to connect its Session OS to external coding CLIs without pretending to be the runtime itself.
What a runtime adapter does
Section titled “What a runtime adapter does”A runtime adapter gives Jarvis a stable contract for each supported coding CLI:
- launch a managed session from the Jarvis UI
- discover compatible sessions that were started outside Jarvis
- attach terminal output to the control tower
- inject Jarvis worker MCP reporting tools for managed worker sessions
- translate runtime-specific signals into a common session model
The adapter layer is why Jarvis can present Claude Code, Codex, and OpenCode in one workspace while still respecting the differences between their CLIs, auth models, and permission flows.
Why Jarvis uses adapters instead of wrapping one CLI
Section titled “Why Jarvis uses adapters instead of wrapping one CLI”Each runtime exposes different control surfaces:
- Claude Code is centered on an interactive terminal session with native hooks and transcript files.
- Codex combines terminal control with its own app-server and config layers.
- OpenCode uses a sidecar-shaped session model with HTTP, WebSocket, and permission APIs.
Jarvis does not flatten those differences away. It normalizes only the parts that matter for orchestration: session lifecycle, visibility, intervention, and low-noise context sharing.
How to choose a runtime
Section titled “How to choose a runtime”Use the runtime that already fits how you work locally.
- Claude CodeSupported if your main flow is Anthropic’s official CLI and you want strong transcript visibility plus optional gated approvals.
- CodexSupported if you already work in the OpenAI Codex CLI and want Jarvis to supervise sessions without replacing your existing config.
- OpenCodeOptional if you want a sidecar-backed runtime with structured permission handling and terminal attachment through the OpenCode session APIs.
If you are deciding from scratch, start with the CLI you already trust for direct terminal use. Jarvis works best as a control plane for a runtime you would still be willing to use outside Jarvis.
Credentials and local CLI ownership
Section titled “Credentials and local CLI ownership”Jarvis does not take over your CLI account state.
- Your Claude Code login stays in your Claude CLI environment.
- Your Codex defaults stay in your Codex CLI configuration.
- Your OpenCode auth and provider setup stay in your OpenCode environment.
For managed worker sessions, Jarvis adds only the minimum launch-time glue it needs:
- an MCP configuration so the worker can call Jarvis reporting tools
- a session-specific prompt prefix so the worker knows its Jarvis session ID
- runtime-specific launch flags or per-workspace config needed for that single session
Current behavior by runtime:
- Claude Code: Jarvis uses temporary launch-time settings and MCP files instead of editing your global Claude config.
- Codex: Jarvis preserves your user-level Codex config and may add project-scoped MCP settings in the session workspace so managed workers can report back.
- OpenCode: Jarvis connects through the local OpenCode session and sidecar surfaces rather than importing or replacing your global account credentials.
That separation matters operationally: if Jarvis stops running, your CLI should still remain your CLI.
Managed sessions vs discovered sessions
Section titled “Managed sessions vs discovered sessions”Managed sessions are launched by Jarvis. Jarvis can inject worker MCP reporting, keep a stronger runtime mapping, and offer more control affordances.
Discovered sessions are sessions you started yourself in a terminal. Jarvis can still discover, index, and often attach to them, but capability depends on the runtime’s local signals and whether the session is safe to take over.