atriumd: keep agents running with the window closed

The background daemon atriumd owns sessions, terminals, and activity state, and the atrium window attaches to it. Your computer runs one for local work; every connected location runs its own.

Practically, that means closing the window no longer kills your fleet, a webview crash no longer takes your agents down, and the menu bar can tell you what's happening while atrium is not on screen.

Quitting vs. closing

On macOS, Cmd+Q opens a progressive HUD rather than quitting outright:

• Tap Cmd+Q again — detach while Keep agents running when atrium closes is enabled. The daemon keeps agents running. With that setting off, the second press quits the runtime.
• Hold Cmd+Q for about 1.4 seconds — full quit, with a progress ring. The runtime is SIGTERM'd and shut down in order.
• Esc or click away — cancel.

Closing the window also detaches while Keep agents running when atrium closes is on.

On Windows, use the caption close button or Alt+F4. The same setting decides whether agents keep running; the macOS hold-to-quit gesture is not used.

Background & startup settings

Settings → General → Startup:

• Keep agents running when atrium closes (on by default) — closing the window detaches instead of quitting.
• Start atrium at login (off by default) — starts the runtime in the background at login. macOS uses a per-instance launchd agent; Windows uses a per-user startup entry.
• View runtime logs — opens a live view of the background runtime's logs.

The menu bar

The tray icon is the atrium mark, embedded as a monochrome template image so it adapts to a light or dark menu bar. It turns accent-yellow whenever an agent is actively working, so "atrium is doing work" reads at a glance without opening anything.

• The title carries the working count; corner badges carry the counts, with a bare + once they overflow.
• The menu header spells it out: N working · M waiting, or K agents · idle when the fleet is up but quiet.
• Per-agent rows with colored status dots. Click one to focus that pane — reopening the window if it was detached.
• A popover that reuses the real activity sidebar, not a reduced copy: the same cards, the same density options, live updates.

Updates

Updates are idle-gated. atrium folds the fleet's turn state and waits for a quiet moment rather than interrupting a running turn, and it detects version skew between a running daemon and a newly installed app.

If an update leaves you with an app that will not start, recovery is CLI-only by design:

atrium update rollback

This reinstalls the app generation the last update superseded — the previous version is kept on disk at ~/.atrium/previous for exactly this purpose. See Install → Updating.

Durability

The daemon is built to survive being killed, not just to avoid it. Its crash-consistency suite runs repeated SIGKILL cycles and asserts that state is never torn: the contract is no corruption, explicitly not no loss. After a hard kill, PTYs survive, scrollback keeps growing across the gap, un-flushed state is still served, and interrupted runs are marked interrupted rather than left pretending to be alive.

Remote daemons

When you add an SSH server, atrium pairs and provisions atriumd as a service on that Linux box. A paired Mac or Windows PC runs the daemon from its own atrium install. The daemon owns remote terminals, agent processes, rooms, task state, notes, and scheduling; your desktop subscribes to their state over the location's connection.

Closing the desktop window leaves those processes on their owning machine. A recurring task assigned to the remote location can fire with the app closed, provided the machine and its daemon are running. During a network interruption the last-known surface becomes unreachable — read-only; reconnect attaches to the existing sessions and scrollback rather than launching replacements.

Manage server health, credentials, forwarded ports, and daemon updates under Settings → Locations. Update daemon runs provisioning in the background and retains the location's identity. Paired computers manage their own updates. Manage devices allowed to open this computer under Settings → Remote access. See Locations.

Instances and data directories

Each atrium instance owns a data directory and a control socket, and every pane's shell is told which via ATRIUM_DATA_DIR and ATRIUM_SOCKET. Never infer the data directory from a channel name — resolve it from those variables, or you will read another instance's state. See Data directory.

A stale daemon can outlive an app restart. atrium context reports which instance you are actually talking to.