Command Center integration

WatchTower is standalone. Command Center is one client.

WatchTower runs from a plain terminal with nothing else installed. Claude Command Center (CCC) is a desktop app that sits on top of it: it delegates durable delivery to WatchTower and adds a UI, transcript rendering, and local desktop transports. Neither owns the other. This page is the exact boundary, taken from the canonical ownership contract.

You never need CCC to use WatchTower. A couple of optional integrations (an HTTP delegate for one alternate messaging transport, a shared model-default file) light up automatically if CCC happens to be installed on the same machine. Nothing in the core queue, worker, or dashboard path depends on them.

Ownership

Who owns what.

WatchTower owns the control plane

Addressing (worker ids, registered agents, session ids, queue refs). Message delivery intent: send, ask, chats, nudges, outbox retry, TTL, dead-letter, and receipts. Queue-worker lifecycle: config, claim, close, reap, and spawn policy. The durable ledgers under ~/.watchtower.

Command Center owns the desktop surface

HTTP and UI entry points such as /api/inject-input, conversation panes, status pills, and transcript rendering. Local desktop transports WatchTower cannot own portably, like terminal keystroke injection. The managed Codex app-server connection when CCC is running. Local conversation archives and rendering caches.

The dividing line, in one sentence. WatchTower owns durable control-plane semantics; CCC owns local desktop transports, the user-facing UI, transcript rendering, and the managed Codex app-server broker when CCC is running.

Call direction

Who calls whom, and why.

CCC calls WatchTower

when it wants durable delivery semantics: dormant or unknown sessions, queue-worker messages, anything that should survive a CCC restart via outbox retry, or anything that needs a WatchTower receipt.

WatchTower calls CCC

only as a delegate or broker: desktop-only transports like a live terminal tab it cannot type into directly, or managed Codex app-server access when CCC is the local broker. If CCC is absent, WatchTower delivers through a native adapter or parks the message in its outbox.

Loop prevention is explicit. Every WatchTower-to-CCC delegate request carries origin=wt, which CCC honors by never calling back into wt send for the same delivery. If delivery cannot be proven and queueing is disabled, the result is a failure, not a delivered toast.

Reporting success

Delivered means verified landed.

The whole contract exists to prevent two classes of bug: duplicate writers against one session, and delivery paths that report success before a message has landed or been durably queued.

StateWhat it means
acceptedWatchTower accepted the message for durable handling. CCC may say "accepted".
queued / outboxWatchTower could not deliver yet and parked the message for retry. CCC should surface queued state, not "delivered".
deliveredA direct local transport succeeded, or WatchTower returned a receipt-backed result. Only then is it "delivered".

WatchTower receipts are the durable delivery ledger; CCC may render them, but WatchTower owns their state transitions. Codex durable truth is its own on-disk rollout store: app-server notifications are useful for fast UI and receipts, but are not canonical unless persisted and reconciled with the rollout.