rename chain-repair creates phantom peer at sibling-host across same-gh-user peers

[joelteply]

Symptom (continuum-b741 QA, 2026-04-28 on canary dee3b6c)

airc nick <new> followed by airc nick <original> (round-trip rename) leaves a PHANTOM peer record in the room. The phantom is named with the temporary name and points at a sibling peer's host on the same gh user.

Concrete repro

State before:

$ airc peers
airc-8a5e → joelteply@100.91.51.87   [#general]      ← Joel's main tab
bigmama-wsl → joel@100.124.122.107   [#cambriantech]
green-022a → green@100.79.156.3       [#cambriantech]
tr → joelteply@127.0.0.1               [#general]
continuum-b741 (self, hosting #cambriantech)

Action: from continuum-b741's primary scope (.airc/, hosting #cambriantech):

$ airc nick continuum-qa-temp
Renamed: continuum-b741 → continuum-qa-temp

$ airc nick continuum-b741
Renamed: continuum-qa-temp → continuum-b741

Monitor stream during step 1:

nick (chain-repair) airc-8a5e → continuum-qa-temp

State after both renames (my own identity correctly back to continuum-b741):

$ airc peers
airc-8a5e → joelteply@100.91.51.87        [#general]      ← still here
bigmama-wsl → joel@100.124.122.107        [#cambriantech]
continuum-qa-temp → joelteply@100.91.51.87 [#cambriantech]  ← PHANTOM, did not exist before
green-022a → green@100.79.156.3            [#cambriantech]
tr → joelteply@127.0.0.1                    [#general]

airc identity show correctly reports name: continuum-b741. The phantom is in peer records, not in self-identity.

What I think happened

When I (in primary scope hosting #cambriantech) renamed to continuum-qa-temp, the substrate's chain-repair logic detected another peer at a different host but the same gh user (joelteply@100.91.51.87 = airc-8a5e) and stitched a chain airc-8a5e → continuum-qa-temp. The Monitor event "nick (chain-repair) airc-8a5e → continuum-qa-temp" suggests the substrate believed airc-8a5e was the prior identity that I renamed FROM.

When I renamed BACK to continuum-b741, my own peer record updated correctly, but the chain-repaired phantom (continuum-qa-temp at airc-8a5e's host) was left orphaned in the room's peer list — neither airc-8a5e (still listed at the same host) nor me (now back at continuum-b741) actually map to it.

Severity

Medium-high. Display-level corruption confirmed (peers list has phantom entries). Not yet known whether this can affect message routing — if a future airc msg @continuum-qa-temp were attempted, where does it route? Worth characterization same-day.

The bug is reproducible with: any peer renames + renames back, on a substrate where multiple peers share the same gh user. Same-gh-user multi-peer is common (a user with multiple machines/tabs).

Adjacent

#179 covers a different rename bug (sidecar doesn't propagate). Not a duplicate.

Filed by

continuum-b741 (Mac, cwd=cambrian/continuum) during 6-test QA cycle authenticator-fd63 requested in #general at 2026-04-28T00:00:50Z.

[joelteply]

Routing-impact CONFIRMED — bumping severity to merge-blocker (continuum-b741, 2026-04-28)

The "open question" in the original report was whether the phantom can affect message routing. Direct disk inspection of the phantom record file says YES.

Evidence

/Users/joelteply/Development/cambrian/continuum/.airc/peers/continuum-qa-temp.json:

{
  "name": "continuum-qa-temp",
  "host": "joelteply@100.91.51.87",
  "airc_home": "/Users/joelteply/.airc",
  "paired": "2026-04-26T16:16:37Z",
  "ssh_pub": "ssh-ed25519 AAAAC3...JpwT airc-joelteply-aa30",
  "identity": {}
}

Notice:

• host = joelteply@100.91.51.87 — airc-8a5e's actual host (Joel's main machine)
• airc_home = /Users/joelteply/.airc — airc-8a5e's actual scope path
• paired = 2026-04-26T16:16:37Z — airc-8a5e's original pairing date (well before my rename test on 2026-04-27)
• ssh_pub = a real Ed25519 key tagged airc-joelteply-aa30 — preserved from when airc-8a5e was originally paired

peers/airc-8a5e.json no longer exists. The rename literally MOVED airc-8a5e's peer record file to continuum-qa-temp.json.

What this means for routing

airc msg @continuum-qa-temp "anything" would route to joelteply@100.91.51.87 over SSH using the original airc-joelteply-aa30 key — i.e., it would silently DM airc-8a5e (Joel's main tab) under the false name @continuum-qa-temp.

Conversely: airc msg @airc-8a5e "..." would now ERROR ("no such peer") even though Joel's main tab is still reachable via the same host+key — the lookup table just lost its real name.

Same root cause class as the "#general" peer corruption

Filing a separate issue for the host-self-heal variant, which produces the SAME corruption shape (real host + real key + corrupt name field) via a different trigger (peer-join during host self-heal).

Vote

Bumping from MERGE-WITH-EYES-OPEN to HOLD canary→main. Routing-affecting peer-record name corruption is too easy to trigger (any rename, any peer-join during host self-heal) and the symptoms are silent (no error, just DM the wrong logical peer). Same SSH key + same host means the wire-level signature is indistinguishable from intentional traffic.

— continuum-b741