Cockpit Overview

What Cockpit is, the operating model, and the section map

AIWG Cockpit

Prompt-first procedure: Describe the outcome you want in your agent conversation. The agent should select and load the appropriate AIWG assets, explain material changes, request any needed approval, and report verification evidence. Exact commands and flags appear only in the CLI reference.

Local control plane for AIWG and multi-stack agentic sessions.

Cockpit is the operator console for agentic work: observe live agent sessions, attach to terminals, handle approvals, launch runtime targets (host, container, VM), recover stale agents, and coordinate AIWG actions — all from one local, token-gated surface. It fronts the AIWG CLI and the agentic-sandbox executor; it replaces neither.

Use AIWG to complete this documented outcome: Cockpit is the operator console for agentic work: observe live agent sessions, attach to terminals, handle approvals, launch runtime targets (host, container, VM), recover stale agents, and coordinate AIWG actions — all from one local, toke
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

The Bridge serves the UI at `http://127.0.0.1:8140` by default and expects an agentic-sandbox executor at `http://127.0.0.1:8122`.

The model in one paragraph

Cockpit is a session-control surface, not a CLI runner. Agents run the CLI; you direct the agents. An action button injects a command into an agentic session, and the agent in that session runs it. Control-plane requests (lifecycle, approvals, session create) go through a local token-gated Bridge; the terminal data plane uses a Bridge-owned attach URL so executor credentials remain outside browser state. Cockpit is opt-in and separately published — nothing here ships in the base `aiwg` npm package.

Section contents

Page	Covers
Installation	Install and launch paths (CLI, direct npm, dev workspace, desktop, VS Code), version pinning, troubleshooting
Connection Doctor	Topology-aware Bridge/executor, listener, runtime-tier, and persistence diagnostics
Guided Headless Deployment	SetupManifest-driven same-host/cross-host planning, staged services, and scoped rollback
Architecture	Shells → Bridge → executor topology, control vs data plane, component map, ports, the serve↔cockpit relationship
Surfaces	All 11 tabs — Home, Inventory, Running, Missions, Sessions, Approvals, Explore, Library, Telemetry, Memory, Actions — plus the launch/start modals
Sessions	The observe-first attach model: take control, replay, per-session persistent terminals, backends, response detection
Bridge API	Every Bridge endpoint, request gating, environment variables, audit events
Trust & Security	Token/CSRF/origin gating, OS keychain (strict mode), runtime/transport/daemon posture badges, the audit log, library invariants
Recovery	Stale-agent recovery for Docker and VM runtimes, destroy fallbacks, host-daemon guidance
Development	Dev/test/mock/release patterns: one-command bring-up, port allocation, the automated-test-only mock boundary, verification tiers
Releases	How `@aiwg/cockpit` ships: channels, publish leg, pre-tag gates

What Cockpit is not

Not a replacement for `aiwg`. The CLI remains the source of truth for

install, deploy, discovery, and maintenance operations.

Not an agent runtime. Agent execution belongs to the provider stack and

the agentic-sandbox executor.

Not cloud-hosted. The surface is local-first: loopback Bridge,

token-gated browser/VS Code/Tauri shells, operator-owned runtime files.

Quick orientation

New operator? Start with Installation, then let the

Home tab's first-run tour walk you through starting a session.

Something's stuck? Recovery covers stale agents on every

runtime family, including the VM path added in 2026.7.

Building on Cockpit? Architecture and

Bridge API are the contract; the Development page has the one-command dev bring-up.