[bug] A machine's identity is os.hostname(), so one laptop is three machines — and a pin to a name it no longer uses answers every call with "run pags up" while pags up is running

[serge-ivo]

Reported

pags up is running, but the agent's Settings shows RLs-MacBook-Air twice, both offline.
Why doesn't it show online? Should we limit clients to one per machine?

Answer to the second question first: no — one-per-machine is already enforced (the RelayDO
rejects a second runner on the same hostname with 4409 unless --force). There are not two clients.
There is one machine wearing three names, and the agent is pinned to one it stopped using.

Measured, live, on this account

$ hostname                     Mac
$ scutil --get ComputerName    RL's MacBook Air
$ scutil --get LocalHostName   RLs-MacBook-Air
$ ps                           pags runner connect <17 instance ids>   (PID 30591, started 06:39 local)
                               16 ESTABLISHED sockets → 2606:4700:…:443

GET /v1/terminals/nodes — four "machines", which are really two:

node	connected	last seen
Mac	true (16 instances)	now
RLs-MacBook-Air.local	false (16 instances)	2026-08-07 09:20
RLs-MacBook-Air	false (2 instances)	2026-07-16
Sergeys-Mac-mini.local	true (4 instances)	now

The first three are the same laptop. It has minted a new identity every time os.hostname()
changed — which on macOS it does, because hostname follows the DHCP/network-supplied name and
flips between the .local mDNS form and whatever the network hands out. ComputerName and
LocalHostName are stable; hostname() is the one field the runner uses and the one that moves.

GET /v1/instances/cda75e28…/runner-node:

{ "runnerNode": "RLs-MacBook-Air.local",
  "nodesDetail": [ { "node": "Mac", "connected": true,  "nodeOnline": true },
                   { "node": "RLs-MacBook-Air.local", "connected": false, "nodeOnline": false } ] }

GET /v1/relay/cda75e28…/status?node=Mac → {"connected":true}.

So the socket is up. The pin names a machine that no longer exists.

What that costs

getBoundRunnerConn (lib/runner-client.ts:80-87) treats a pin as authoritative and deliberately
does not fall back — correct, and its comment says why: falling back would run the agent "on a
machine the user did not choose, in a different checkout". Pinned + dead → null.

Every runner-backed call on that instance therefore returns:

terminal_list_targets → "No runner is connected for this agent — run `pags up` on the machine
                         whose terminal you want to control."

…while pags up is running, on that machine, with a live socket, 16 instances attached. The one
remedy the platform offers is the one thing the user has already done. This is the root cause of
#378 (the Terminal tab); that ticket is about how badly the state is presented, this one is why
the state exists at all.

Nothing heals it and nothing reaps the dead rows: a node row from 2026-07-16 is still in the picker
three weeks later, indistinguishable from a machine that is merely asleep.

Why "both duplicates are offline" is the honest reading of the screen

machineTile (store/console/src/lib/runnerPanel.ts) renders one tile per runner_node string.
The two tiles the user recognises as their laptop — RLs-MacBook-Air and RLs-MacBook-Air.local —
are both genuinely offline. The tile that is their laptop is called Mac, which reads as some
other machine. The picker has no notion that a machine can be renamed, so it cannot say so.

Suggested direction

1. Give a machine a stable identity. Mint a UUID once, persist it next to the session
   (~/.config/proagentstore/), and send it as the node key; keep hostname() as a mutable
   display label. normalizeRunnerNode (lib/runtime-nodes.ts) is a trim+slice over a
   user-visible string being used as a primary key — that is the whole defect in one line.
2. Heal or flag a pin whose machine is gone. /runner-node already returns everything the
   sentence needs: pinned node offline, exactly one live node. Either auto-repoint with a notice, or
   say it out loud — "pinned to RLs-MacBook-Air.local, last seen 21h ago; this machine now reports
   as Mac — repin?". Silent-and-authoritative is right for routing and wrong for the UI.
3. Reap or fold stale nodes. A node not seen for N days should leave the picker (or offer
   "forget this machine"). Merging on a stable id makes this mostly unnecessary.

Workaround today: Settings → Runner → Runs on → pick Mac, or set it to Automatic (unpinned
routing already scans for whichever node holds a live socket — getLiveRunnerConn).

Related: #378 (the surface that shows this state), #238 (/runtime/status and the stale default
row), #241 (a stale offline verdict outliving its sessions).

Files: packages/cli/src/commands/runner/relay.ts:27,213, packages/cli/src/commands/runner/http.ts:53,
workers/api/src/lib/runtime-nodes.ts, workers/api/src/lib/runner-client.ts:73-116,
workers/api/src/routes/terminals.ts, store/console/src/lib/runnerPanel.ts,
store/console/src/components/RunnerPanel.tsx.

[serge-ivo]

Self-review: fix (1) is a fleet-wide compatibility break if done as a key swap, and fix (2)'s auto-repoint contradicts the invariant this ticket cites

1. runner_node is not just a label — it is a routing key, and it names a Durable Object.

relayNameForInstance(instanceId, node) → ${instanceId}:node:${node} is the DO identity, and the same string is a key in instance_runtime_nodes, in coding_sessions.runner_node, and in config.runnerNode pins. Swapping it for a UUID changes every relay DO name at once: an already-running pags up (any version older than the change) keeps connecting to the hostname-named DO while the server looks for the id-named one, and every instance on every machine goes unreachable until both sides are upgraded. suspendSessionsFromOtherNodes and reassignSessionNode compare the same string.

So it has to be additive, not a rename: add a stable node_id alongside runner_node, have the server accept and match BOTH during a soak, keep the hostname as a display label, and migrate pins once the fleet reports an id. Doing it as a straight key swap is a self-inflicted outage of the exact kind this ticket is about.

2. Withdrawing the auto-repoint half of fix (2). I offered "either auto-repoint with a notice, or say it out loud". Auto-repointing directly contradicts the reasoning I quoted approvingly from getBoundRunnerConn: a pin exists so the agent never runs "on a machine the user did not choose, in a different checkout". A hostname change is indistinguishable, at the server, from the user having genuinely moved to a second machine — the whole problem is that identity is unstable, so nothing here can safely infer intent. Surface it and let the user click. The one-line sentence (pinned to X, last seen 21h ago; this machine now reports as Y — repin?) is the whole fix and carries no risk.

3. Fix (3), reaping stale nodes: hide, never delete. A node not seen for N days may be a laptop that is merely closed; deleting its row would drop pins and orphan coding_sessions.runner_node values pointing at it. Filter it out of the picker and offer an explicit "forget this machine", which is a user action with a confirmation, not a cron.

The diagnosis — three node identities for one laptop, a pin naming a machine that no longer exists, every call answering run pags up while it is running — is re-verified and unchanged.

[serge-ivo]

Already delivered — closing, and it is now confirmed working on the reporting account.

Shipped in d0e4095 ("a machine is not its hostname, and a dead pin must not read Connected."), with the Terminals-side fold following in fa0a24a / a5e2e8a (#393).

The fix took the self-review's direction, not the ticket body's:

1. Stable identity, additive. machine_id rides alongside runner_node (migration 0098); the hostname keeps its job as routing key, relay DO name and display label. No relay DO was renamed, so no fleet-wide outage — the key-swap this ticket originally proposed is exactly the failure it reports, inflicted on everyone at once.
2. No auto-repoint. A dead pin resolves through aliasNodesFor to another name of the same machine, proven by a recorded id — which honours the pin rather than falling back from it, leaving getBoundRunnerConn's no-fallback contract intact. Unprovable renames stay refused and are surfaced (pinnedWarning → renamed).
3. No reaping. Stale nodes are folded, not deleted; the explicit "forget this machine" landed under [bug] One laptop still shows as three machines — nothing has claimed an id yet, the stale names can never be claimed, and the Terminals page does not fold by machine #393.

Live, on the account this was reported from (GET /v1/terminals/nodes, just now):

node='Mac'  machineId=3901c9c4-004f-435e-bfc5-0b87b7ac5173
            aka=['RLs-MacBook-Air', 'RLs-MacBook-Air.local']  v=0.4.40  connected=True
node='Sergeys-Mac-mini.local'  machineId=None  aka=[]  v=0.4.22  connected=False

The four rows in the report are two machines. Mac, RLs-MacBook-Air.local and RLs-MacBook-Air have taken one machine_id and fold into a single entry carrying the other two as aka — so the reported screen ("RLs-MacBook-Air twice, both offline") no longer exists, and the six instances pinned to the middle name route to the live socket.

Closing. The residue this uncovered — that nothing could forget a machine, and that a pre-0.4.40 runner was silently unidentifiable — is #393, now also delivered.