[bug] pags up freezes its instance list at startup — a newly-eligible agent never attaches

[serge-ivo]

What happens

packages/cli/src/commands/up.ts fetches the instance list once:

const res = await fetch(`${API_BASE}/v1/instances/my/instances`, …)   // :64
const active = (data.instances || []).filter((i) => i.status === "active");
instances = instances.filter((i) => i.capabilities?.runtime != null); // :83
const args = [cliPath, "runner", "connect", ...instances.map((i) => i.id)]; // :117

runner connect then serves exactly that frozen set for the lifetime of the process. There is no
re-fetch, no watcher, no periodic refresh.

So any instance that becomes eligible AFTER startup is invisible to the running runner:

• subscribe to a new coding/browser agent
• an existing agent's capabilities.runtime changes from null (e.g. a capability edit, Wire declarative capabilities (surfaces/runtime/workflow/tools) through create + update — the missing authoring path (#51) #141)
• an instance flips from inactive to active

The machine keeps showing online (its other instances are attached), while the new one shows
"machine online, agent not attached" — the amber state in Settings → Runs on. Nothing says
why, and nothing suggests the fix.

Observed 2026-08-06: an FWS Repo Coder sat amber with pags up running and CLI 0.4.29; a
pags up restart turned it green immediately.

Fix

Re-enumerate periodically (or on a server push) and connect newly-eligible instances without a
restart. runner connect already manages one socket per instance, so adding one is not a
restructure.

Failing that, at minimum: make the gap visible. pags up prints the instances it found at
startup (:99–101) — the console should be able to say "this agent is not in your runner's list;
restart pags up" rather than an unexplained amber dot.

Verification

• Start pags up, then subscribe to a coding agent. It attaches without a restart.
• The startup list and the console's per-instance connected agree.

[serge-ivo]

Duplicate of #229, which predates this and is considerably more thorough (membership manager, discovery loop, multi-machine/pinning constraints, acceptance criteria). I've moved today's observation there as a comment. #237 stays open — it covers the observability gap (an amber dot with no cause or remedy), which #229 only touches for auto-discovered instances.