Control After Launch

Managed sessions stay reachable after the terminal closes. Send to them, tail them, or continue them later from the browser, CLI, or API.

Managed vs unmanaged. Sessions started with bare provider CLIs are imported as unmanaged history—they land in the timeline but Longhouse does not own their live control channel. Use longhouse claude or longhouse codex as the normal launch path when you want a session to stay steerable long after the terminal closes.

Provider truth matters. Claude Code, Codex CLI, Cursor Agent, OpenCode, Pi Agent, Oh My Pi can be steered mid-turn. Antigravity CLI takes send alone. The timeline offers each session only the controls its provider can actually perform.

How it works

A bare claude or codex command runs a session that is only reachable in the terminal where you started it. When you launch a managed session through Longhouse instead, Longhouse keeps a control channel open alongside the session:

terminal

longhouse claude    # starts Claude Code with control channel
longhouse codex     # starts Codex CLI with control channel

The session still runs in your terminal. The difference is that Longhouse can reach it later — from another terminal, the browser, or the API. One session, one execution owner, but multiple surfaces to observe and interact with it.

What you can do with a control channel

See what is running

The timeline is the primary view. The same data is one query on the Machine API, which is what scripts should use — there is no wall subcommand on either binary.

terminal

curl "http://localhost:8080/api/agents/sessions/wall?days=7"

Watch recent events

terminal

longhouse-server tail SESSION_ID --roles user,assistant

Send a message

terminal

longhouse-server send SESSION_ID "Check the failing test in auth.py"

The message lands in the session's directed inbox and is persisted before any delivery attempt. A running session picks it up and acts on it; a stopped one still has it waiting.

Continue later

When you come back to a session that has stopped, continue it with the follow-up you want it to pick up:

terminal

longhouse-server continue SESSION_ID "Now run the integration tests"

This works from the browser too — open the session detail page and use the continue action.

Browser and CLI stay in sync

The timeline, session detail, wall query, tail, and send all point at the same session surface. Actions you take in the browser are visible from the CLI and vice versa. There is no separate "browser session" or "CLI session" — there is one session with multiple ways to reach it.

Which command should you start with?

Situation	Command
Quick local task you still may want to inspect later	`longhouse claude` / `longhouse codex`
Long-running work you want to check on later	`longhouse claude` / `longhouse codex`
Work on a remote machine you want to steer from your laptop	`longhouse claude` / `longhouse codex`
Coordinating multiple sessions on the same project	`longhouse claude` + `longhouse-server peers`

Bare provider CLIs still import. That compatibility path exists so Longhouse is useful on day one, not because it is the recommended steady state. Managed sessions launched through Longhouse keep the control channel open so you can send to them, tail them, or continue them from any surface.

For the full list of CLI commands, see the CLI Reference. For the HTTP endpoints behind these commands, see the Machine API.