[bug] A "Runs on" tile claims "Attached · online" for a node the pin excludes — one line below "Status: Offline", and the invariant test only covers the pinned tile

[serge-ivo]

A "Runs on" tile says "Attached · online" for a machine nothing routes to, one line under "Status: Offline"

The owner's report was "why does it say runner offline if in settings the node is online". Both statements are on screen at the same time, in the same card, and the tile is the wrong one.

With the instance pinned to machine A and a live socket on machine B, RunnerPanel.tsx renders Status: Offline (pin-aware, correct) and then the "Runs on" grid, in which B's tile is green and labelled "Attached · online".

Mechanism

store/console/src/lib/runnerPanel.ts:112-114:

attached = m.instances.some(i => i.instanceId === instanceId && i.connected)

fed by workers/api/src/routes/terminals.ts:381-383, where connected = relayConnected(instanceId, node) — a bare socket probe with no pin. So "attached" is asserted about routing from a fact about connectivity. Nothing routed there: getBoundRunnerConn (lib/runner-client.ts:74-107) is pin-authoritative and never falls through.

The invariant that was supposed to catch this only covers the pinned tile

runnerPanel.ts's own header promises the tile is "derived from BOTH readings, so a disagreement is a test failure rather than a screenshot". But machinesToShow (:82-95) merges the two readings only for the synthesised tile, and returns [...machines] untouched whenever the pinned node already appears in the Terminals list. The test at store/console/src/lib/runnerPanel.test.ts:103-119 iterates only over the pinned node's tile (machinesToShow([], "laptop", …)).

A tile for a non-pinned node holding a live socket is untested. Grepped — that is the gap.

The Terminals page (/v1/terminals/nodes) shares the same rows and the same blindness.

The one surface that told the truth

diagnoseAttachment (routes/instances.ts:860-866) renders, correctly: "This agent is pinned to , which isn't connected. is connected — set 'Runs on' to (or Automatic)". It sits directly above the tile that contradicts it.

Second, independent divergence — same family, different file

workers/api/src/routes/coding-shared.ts:53-54:

export async function getSessionRunnerConn(env, instanceId, uid, session) {
	return getRunnerConn(env, instanceId, uid, session.runnerNode ?? null);
}

Routes by the session's stamped node — no pin, no alias, and no relay live-check: only status != 'offline' on a column that is never cleared on disconnect. /capture derives runnerConnected from it (coding.ts:223), and resolveRunnerOnline gives a live session's capture priority over the relay answer (if (hasActiveSessions && capture === false) return false). So a session stamped to a machine the owner has left makes the Coding tab report offline while the header dot reports online.

f8ddc272… held exactly such a session — csess_c960d431…, runnerNode: "Sergeys-Mac-mini.local", active from 2026-08-11 21:32:49 until 07:44:51 on 2026-08-12, i.e. through the incident. /coding/browse (getDefaultRunnerConn) and /coding/diagnostics bypass the pin the same way; coding-repos.ts:195-200 already documents this set as measured.

Split this into its own issue if it is cleaner to fix separately — it is filed here because it is the same defect class (a surface claiming attachment it never verified) and was found in the same trace.

Acceptance criteria

1. A tile for a node the pin excludes does not claim "Attached". It may still show the machine as connected — connectivity and attachment are different facts and the label must say which it means.
2. machinesToShow's stated invariant holds for every tile, not only the synthesised one, and the test iterates a non-pinned node with a live socket.
3. The Terminals page distinguishes the same two facts.
4. getSessionRunnerConn live-checks, or its callers stop treating its answer as authoritative for "is the runner online".
5. A test with pin=A, live socket on B, asserting the card cannot render "Offline" and "Attached" for the same instance simultaneously.

Verified vs inferred

• Verified: every file:line; the pin-blindness of terminals.ts:381; the test's coverage of only the pinned tile; the stamped session's node and its active window.
• Inferred: that the owner's screen showed the green tile at 07:44. He reported the contradiction and the code produces it deterministically in that state, but no screenshot was captured, and the pin has since moved so it cannot be reproduced without repinning.

[serge-ivo]

AC 1, 2, 3 and 5 fixed in 2c4ba97, deployed (CI 31579182801, Deploy Host Worker 31579182768, Deploy API Worker 31579182757 — all success).

This issue stays OPEN for AC 4. See the scope note at the bottom.

What changed

machineTile now separates the two facts it was conflating:

• socket — this agent holds a live relay socket on that machine. A fact about a WebSocket, reported by a pin-blind probe on both feeds (terminals.ts:381 and nodesDetail[].connected in instances.ts:483).
• routesHere — this agent's runner calls actually go there. Decided by the pin, because getBoundRunnerConn is authoritative and never falls through.

A fourth tone connected (amber) renders Connected · this agent runs on <pinned machine>, so a reader learns why nothing runs there instead of reading a green "Attached · online" one line under a correct Status: Offline. Green is now reserved for "work runs here." Since both feeds are pin-blind and only one of them is in this issue's file set, the pin is applied where the sentence is chosen — which is where the pin already was: machineTile receives it.

AC 2 — the promise is now true rather than restated. mergeDetail folds /runner-node's reading into every machine, not only the synthesised one; the merge is a union, because both endpoints probe the same relay at different moments, so a disagreement there is a race and not a contradiction. The sweep enumerates pinned-here / pinned-elsewhere / unpinned × socket × machine-up × listed-by-Terminals and asserts, per tile, that "Attached" appears only where routing puts work. Confirmed non-vacuous: forcing routesHere = true fails 4 of them.

AC 3 — Terminals. TerminalInstance gained pinnedNode: string | null. bound:false could not distinguish "no pin" from "pinned elsewhere", and the difference decides the answer — an unpinned agent routes to whichever machine holds a live socket, so a connected chip there is a routed chip. The name travels rather than a second boolean, because the useful sentence names where the work went. /v1/terminals/nodes stays deliberately pin-blind: it is a platform view across every agent and "is there a socket here" is the question it exists to answer.

#379/#393 survive. pinned still matches any aka, and machineTile now also accepts the server's resolvedNode — the only side holding the persisted machine id. Two tests cover a renamed machine staying attached under either proof. The synthesise guard became aka-aware in the same edit, because testing the current name alone drew a renamed laptop twice — a grey "Offline · Pinned" beside a green "Attached · Pinned", about one machine.

Verified

Re-run by the committer after rebasing onto ba67afc, not before: pnpm typecheck, pnpm vitest run (455 files / 7973 tests), biome (1130 files), design-tokens, agents-allowlist, qa-config, file-size, migrations --require-history, test-isolation, docs:drift, and pnpm test:e2e — 370 passed, chromium + webkit, including two new #531 specs at 320px and 390px in WebKit.

Confirmed live in production, not just in CI: the deployed console bundle at https://proagentstore.online/console/ contains Connected · this agent runs on ${n} and the runner-machine-tile testid, with Attached · online still present for the attached branch.

Layout was measured, not assumed: at 320px the status line wraps to two lines (a hostname is one unbreakable token — break-words added), and the Terminals chip needed basis-full for the routing note because sharing a line truncated both the agent name and the hostname.

NOT verified

• The pinnedNode field on /v1/terminals/nodes was not read from live production — that needs an authenticated call. Unit-tested (terminals.test.ts) and its deploy is green.
• The Terminals chip change has no committed e2e — that page is not in the fixture-covered route list. It is covered by pure tests plus manual WebKit screenshots at both widths, not by a standing guard.
• That the owner's screen showed the green tile at 07:44 remains INFERRED, exactly as filed — the code produces it deterministically in that state, but no screenshot exists and the pin has since moved, so it was not reproduced.

AC 4 — deliberately split out, not folded

getSessionRunnerConn (routes/coding-shared.ts:53-54) is untouched, and I re-verified the mechanism before deciding: getRunnerConn (lib/runner-client.ts:22-28) selects on status != 'offline' only — a column never cleared on disconnect — so it hands back a live-looking connection for a machine that has been off for days, and routes/coding.ts:222-223 then answers runnerConnected: true.

It belongs in its own issue because it is a different tree and a different blast radius: a backend routing change across /coding/capture, /coding/browse and /coding/diagnostics with live coding sessions underneath, reaching agents/coder/web/src/runner-online.ts where resolveRunnerOnline gives a session's capture priority over the relay answer. Its acceptance is also phrased as an open design choice ("live-checks, or its callers stop treating its answer as authoritative"), which deserves its own analysis rather than a rider on a console-label fix.

[serge-ivo]

AC 4 has shipped as #532 (28a7d01, deployed and green) — getRunnerConn now asks the relay whether the machine is up, so a session stamped to a machine that has been off for days no longer resolves to a connection, and /coding/browse and /coding/diagnostics resolve consistently with it.

With AC 1, 2, 3 and 5 delivered in 2c4ba97 and AC 4 in #532, this issue has nothing outstanding. Closing.

One thing #532 recorded that this family should keep: AC 2 is improved but not fully closed. All-machines-off now agrees. A-off / B-on still disagrees — /capture on a session stamped to A says offline while /runtime/status says connected for B, and resolveRunnerOnline (agents/coder/web/src/runner-online.ts:36) resolves that to offline by its documented capture-priority rule. Truthful for the session, but the banner then tells someone already running pags up to run pags up — the same family as #524/#530/#531. Closing it needs a per-session sentence rather than a boolean, which is a design question and deserves its own issue rather than a guess.