Rooms, panes and workspaces#
A room groups panes and their layout/context. A pane is one interactive surface. A registered workspace is a host filesystem directory available to agent runtimes. These concepts should not be collapsed into one another.
The current catalog includes 16 CLI types plus Chat, YouTube, VNC, Browser, DeepSeek Harness, Live, Files and Demo Projects. Up to 16 panes can occupy a room. CLI identity selects an adapter; runtime readiness is observed independently.
A project may be referenced from multiple panes. That does not clone its files or create isolated Git branches. Two tools with write access can still conflict unless ownership and integration are coordinated. Browser state, provider-native session state and room layout are also different forms of state.
CLI process, terminal and conversation layers#
A terminal pane combines presentation, transport, a hosted process and often a provider-native conversation. Each layer can fail independently:
- Presentation: xterm geometry, rendering, selection, viewport and scrollback.
- Transport: browser-to-server connections and attachment state.
- Process: shell/CLI lifecycle on the execution host.
- Conversation: provider-native task/session identity and continuation semantics.
- Persistence: application history and retained metadata.
A disconnected WebSocket does not establish that the CLI process died. A visible history record does not establish native resumability. A process exit does not establish successful task completion. Recovery must identify the failing layer and use the supported adapter.
Terminal control ownership/leases help prevent conflicting input where implemented. They do not grant a new user permission to read another user's session. Preserve current input and active work when testing reconnects or resizing terminals.
Evidence for resumed work should include the correct native task reference and real continuing output, not just replayed transcript text. Evidence for a code task should include actual file/result changes and appropriate checks.
Client synchronization and multiple devices#
Clients connect to the same host and authorized application state. Responsive shells adapt presentation for desktop, tablet and phone; available desktop review/window features can expose more of that host across displays.
Opening another client is not a backup, server failover or new execution environment. Host reachability, authentication, TLS and network policy still govern access. Loopback on a phone refers to the phone, not the machine running SpaceApp.
Do not infer offline multi-device synchronization, unrestricted concurrent editing or equal native-window capabilities on every platform. Verify the installed client's behavior and release assets. A wrapper version and backend runtime version can differ.