Federation and Star Map

A PwrAgent profile can federate with PwrAgent on your other machines, a laptop and a workstation for instance, so that each one can see and drive the other’s threads. Every machine keeps running its own agents against its own checkouts; federation lets you reach them from whichever window is in front of you. The Star Map is the view built for that: every project and thread, local and remote, on one map.

Federation is off until you set it up.

Setting it up

Everything lives in Settings → Federation, one section per step:

Configuration — the Mode: gateway listens for peers, client connects to a gateway, dual does both, and disabled turns federation off. This is also where you name the machine. The gateway gives each connected machine a short name, so long host names stay readable on cards and chips.
Capabilities — what enrolled peers may do on this machine (below).
Encryption — the end-to-end encrypted transport between instances.
Invites — Generate invite on the gateway, then Import invite on the machine joining it.
Connection — the runtime state: role, listener, public URL, and gateway endpoints.
Instances — the enrolled peers.
Activity — recent federation events, for diagnosing a connection.
Tailscale and Cloudflare Access — guided setup for reaching a gateway over a tailnet or through Cloudflare.

Once it’s configured, the Star Map button in the title bar doubles as the federation status control: hover it for the connection state, an on/off switch for this app instance, and a preview of the connected machines.

The Federation popover under the title bar's Star Map button. It reads Running, connected, configured on as a client, with an On switch. A small map previews the Star Map, captioned 2 instances, 1 connected, with an Open the Star Map button, and a Traffic chart covers the last 60 seconds of data sent and received. — Hover the title bar's **Star Map** button for federation's state, an on/off switch, recent traffic, and a way into the Star Map.

Capabilities

Each machine decides what its peers may do to it. Changes save immediately and reconnect federation, which closes any open remote terminals.

Switch	Default	Lets peers
Allow remote shells	On	Open terminals on this machine.
Allow incoming files	Off	Push files here, into Incoming files folder (your Downloads folder unless you set one). Existing files are never overwritten, and nothing opens automatically.
Allow file pull	Off	Read files from this machine in remote thread viewers, limited to the thread’s directories.
Allow file pull outside thread directories	Off	Read any file PwrAgent can read on this machine.

Settings, Federation, Capabilities. Allow remote shells is on. Allow incoming files is off, with an Incoming files folder that defaults to Downloads and Check access and Open folder buttons. Allow file pull and Allow file pull outside thread directories are off. Below, PwrAgent Encrypted Transport lists its protocol: Noise IK, X25519, AES-256-GCM, SHA-256. — **Settings → Federation → Capabilities**: what other machines may do to this one.

Working across machines

With peers connected:

Remote threads mount into viewer windows with the live transcript and pull-request state, and you drive them the same way as local ones. Connected machines are listed in the Profiles menu under Remote Instances.
Remote terminals open on the peer, rooted in the thread’s workspace, when that peer allows remote shells.
Quick jump (Command+K, or Control+K on Windows and Linux) searches threads on every connected machine.
Choose where new work runs. The new-thread menu has a New chat on list of machines. A thread’s right-click Sub-thread in New Worktree (or New Workspace) action opens a New worktree on / New workspace on list, with the parent’s machine first.
Mentions. The composer’s @ autocomplete lists federated machines and profiles alongside directories.
Files. Agents can push files to a peer that allows incoming files. Markdown files a remote agent wrote open in your local viewer when the peer allows file pull.

Settings, Federation, Instances. One peer, riley-workstation, is listed as the gateway and connected, with its protocol, capability count and instance ID, the time it connected, and the capabilities it offers, from receiving thread group changes to announcing directory changes. Controls follow for its icon, a short name, and Browse remote threads. — **Settings → Federation → Instances** lists each connected machine and what it can do. **Browse remote threads** opens its threads in a viewer window.

Send a thread to another machine

Right-click a Codex thread and choose Send to Another Machine… to continue the conversation somewhere else, history included. Pick the machine, then:

Copy keeps this thread, and a new thread continues on the other machine.
Move does the same, then archives this thread once the copy is verified. Its worktree stays on disk.

When the thread has a project, the dialog finds the matching clone on the other machine (by its origin, or by name if it has to) and carries the Git state across: commits the receiver lacks, plus staged, unstaged, and untracked changes. The pull-request link, schedules, messaging bindings, and ignored files stay where they were. Sending waits for a running turn to finish, and the other machine must allow incoming files.

The Send to Another Machine dialog for the thread Fix focus order in the address form. The machine list holds riley-workstation, marked Incoming files off. Copy is selected over Move. A summary says what is sent, history and commits the receiver lacks plus staged, unstaged and untracked files on main, and what stays here: the pull request link, schedules, messaging bindings and ignored files. The Copy button is unavailable. — Sending needs the other machine to allow incoming files. Here it doesn't yet, so the machine reads **Incoming files off** and **Copy** waits until that machine turns on **Allow incoming files**.

Star Map

The title bar’s Star Map button opens the Star Map in its own window. Projects sit at the centre of their own systems and threads orbit them as cards, for every connected machine as well as this one. Pan and zoom freely — fly with W A S D, drag cards to arrange them, marquee-select several at once, and filter with chips. A layout switch arranges the map by Lanes, Instances, or Projects, and arrangements persist.

The Star Map in its Projects layout, centred on the storefront project with six threads. Thread cards orbit it, including two from riley-workstation, which carry that machine's name. The other projects, docs-site, billing-service, search-indexer, mobile-app, media-worker and infra, sit at the edges with arrows pointing toward them, and a key at the bottom left lists W, A, S and D to pan, minus and plus to zoom, Shift for faster, and 0 to reset. — **Projects** puts each project at the centre of its own system, with its threads in orbit, whichever machine they run on.

Floating chat cards carry a real Markdown composer, so you can send a turn without leaving the map, and Command+K (Control+K) flies straight to a thread. The Manager chip asks the Star Map manager, an agent that can see the open map and highlight, open, pin, move, archive, or fly between threads for you.

It’s the surface for “I have thirty threads across six repos and two machines and want to see the shape of it”, not a replacement for the sidebar.