Longhouse Provider Integrations

Longhouse provides one session archive and capability model for Claude Code, Codex, OpenCode, Antigravity, and Cursor. It does not replace provider CLIs, their terminal UIs, or their native session identities.

Each provider has a different archive format and control surface. Longhouse exposes a capability only when the provider and current session control path support it.

Operating model

Shadow

Sessions discovered from native files or databases. They are searchable and observable, but Longhouse does not control the provider process.

Helm

Sessions launched through Longhouse that retain the provider's normal interactive terminal UI. Longhouse owns a separate control path.

Console

Sessions launched from Longhouse UI. A provider invocation is scoped to a turn while the durable thread remains after the process exits.

Managed control uses the user-installed upstream CLI. It does not imply that Longhouse owns the provider binary.

Archive sources

The normalized timeline is not a replacement transcript. Longhouse retains provider-native source evidence and projects only records whose meaning is known. This preserves a path to re-render a session when a provider changes its format or exposes a previously unknown record type.

Source fidelity rules

JSONL is incremental, not uniform

Claude and Codex are both JSONL sources, but their identity rules differ. Claude subagent and workflow transcripts require filtering so control ledgers do not appear as empty sessions. Codex session metadata establishes the canonical session ID and fork parentage even when the filename is not sufficient.

SQLite needs live-safe reads

OpenCode and Cursor write while Longhouse is reading. Their adapters are read-only and WAL-aware. Filesystem events on WAL and shared-memory sidecars are mapped back to the canonical database rather than treated as independent sessions.

Raw data is retained separately

Cursor storage is a content-addressed graph. Longhouse stores exact observed metadata and blob bytes, then emits a versioned render projection for text, reasoning, tools, and results. Unknown graph fields remain durable raw records with typed render gaps.

Identity must be provider-backed

Longhouse does not bind a managed session to the newest local file. Provider session IDs, hook claims, database identity, and launch identity must agree. Time, working directory, and process recency are diagnostics, not binding proof.

Claude Code

longhouse claude runs the stock Claude terminal UI with a private local channel. The channel binds to the managed session and provides input injection. Interrupts are limited to the matching Claude process through process-identity checks.

The channel is a local MCP server used as a control path, not a replacement Claude runtime. Longhouse receives the channel capability, then sends a session-scoped injection request to the local bridge. A steer request carries explicit steer intent and is gated on a fresh active runtime phase; a normal idle injection is not represented as steer.

Managed Claude state records the provider session identity and the exact process identities for Claude and the local channel. Local health derives liveness from process scanning. A degraded bridge or closed foreground TUI is not permission to terminate Claude; later continuation uses the provider's persisted session identity.

• Send input, interrupt, active-turn steer, and answer a pause.
• Reattach or continue using the native session identity.
• Remote launch uses the same channel under a detached terminal wrapper; there is no separate one-shot Console adapter.

Codex

longhouse codex resolves the stock codex binary from PATH, starts Codex app-server, places a local WebSocket relay in front of it, and attaches the stock TUI to that server.

The bridge has three different execution shapes. TUI-attached managed mode keeps the user's terminal connected to app-server. Detached-UI managed mode keeps app-server and the bridge alive without a local TUI, which is the remote-launch path. Console is separate prompt-and-exit execution and must not be conflated with detached-UI control.

Bridge state contains the Longhouse session ID, process identities, relay URL, and launch mode. A nonzero exit from the remote TUI attach client is treated as a foreground-link failure. It does not end the bridge or app-server. Only clean user exit or explicit terminate/stop actions can end managed execution.

• Send input, interrupt, active-turn steer, answer a pause, and reattach or continue.
• A detached TUI does not imply that the managed session has ended. The bridge remains until an explicit stop path terminates it.
• Console uses a separate one-shot execution adapter.

OpenCode

longhouse opencode runs stock opencode serve on loopback and attaches the normal OpenCode UI. Bridge state retains the local server address, provider session identity, process identity, and credentials needed to reconnect.

The bridge state is private to the session and uses a local server password. A launch retry first checks for a healthy state file and reuses the existing server. It does not create another opencode serve process for the same Longhouse session.

Liveness has separate checks for the recorded process identity, authenticated local server health, and the presence of a foreground attach TUI. An attach-client failure leaves a healthy server available for reattach. An alive process with a failed health probe is reported as degraded rather than being relabeled as an unmanaged Shadow session.

• Input maps to OpenCode's prompt API. Interrupt maps to its abort API.
• Managed server launch is idempotent per Longhouse session, preventing duplicate servers after retries.
• Supports send, interrupt, terminate, reattach, and turn-scoped Console execution.
• Does not advertise active-turn steer or pause-answer.

Antigravity

longhouse agy runs the user's agy CLI and installs a hook/plugin adapter. The adapter records phase and transcript-binding information and exposes a private input inbox.

The hook adapter receives provider lifecycle events including invocation, tool, and stop boundaries. Input messages are written as private inbox records with bounded size and expiry. A hook atomically claims an eligible message and returns it as an injected user message. The sender waits for the claim record rather than assuming that writing the inbox changed model context.

The adapter can request continuation at a provider-defined boundary while pending input exists. That is still not a stable remote process-control channel. There is no supported reattach lease, interrupt operation, or remote execution mode.

• Remote input is queued and claimed by the next provider-defined safe hook boundary before delivery is reported.
• Supports safe-boundary input injection only.
• Does not support remote launch, reattach, interrupt, terminate, active-turn steer, pause-answer, or Console execution.

Cursor

Helm

longhouse cursor reserves a native Cursor chat identity and runs the stock cursor-agent TUI in a PTY. Hook evidence and the native store.db source must agree before the managed session is bound.

Cursor's durable source is a content-addressed blob DAG. The root snapshot provides ordered message references; message blobs contain text, reasoning, tool calls, and tool results. The store does not provide reliable per-message timestamps, so archive ordering is source-first rather than timestamp-first.

Helm control uses a mode-0600 per-session Unix socket. Idle send is protected by native hook phase evidence. The provider's TUI has a specific submit sequence, but Longhouse does not write to the PTY unless the bound conversation is known idle. This prevents a remote send from cancelling active work or crossing into a different local chat.

• Input is accepted only when the exact Cursor conversation is idle.
• Interrupt uses Ctrl-C only for a verified active generation. Termination is explicit.
• Supports send while idle, interrupt, terminate, and reattach. It does not provide active-turn steer.

Console

Cursor Console runs one stock cursor-agent --print invocation per turn against the same native chat identity. Structured output is written to durable files before it is projected into the timeline. The process may exit after a turn while the Longhouse thread and Cursor chat remain available for a later turn.

Each Console turn is claimed before spawn and records process-group identity, process start time, provider chat identity, and output paths. On Machine Agent restart, a matching live process resumes monitoring from the durable output file. Missing or ambiguous terminal evidence fails the turn without replaying the prompt.

Control and recovery boundaries

Longhouse treats archive state, control ownership, process liveness, and session phase as separate dimensions. A session can remain searchable after a provider exits. A managed session can be degraded when its control transport is unhealthy. Neither state changes execution ownership or authorizes Longhouse to kill the provider process.

Process identity

Interrupt, terminate, and recovery paths verify recorded PID identity and process start time. A reused PID is not treated as the original provider process.

Durable turn claims

Console adapters claim a turn before spawning a provider. A retry returns the existing claim instead of executing the prompt twice.

Explicit degradation

Lost bridge state, a missing TUI, or a failed health probe reduces current capability. It does not silently switch to a different provider mode.

Provider proof

Capability flags are not inferred from source availability. Longhouse requires a provider-native mechanism and targeted operation evidence before advertising an action.

Capability matrix

Archive visibility, runtime state, process liveness, managed ownership, and control availability are separate facts. A provider name alone does not determine whether a session can be controlled.