---
name: unbound-endpoint-unwedge-procedure
description: "Reviving an UNBOUND-by-bind-conflict endpoint on a 0.52.x box — purge is a trap here, correct the record instead; relaunch needs a PTY"
metadata: 
  node_type: memory
  type: project
  originSessionId: 1a65ba75-47f3-49c2-ba56-6ea5a9aa63b6
  modified: 2026-08-04T22:16:38.909Z
---

Field procedure from the deployah lockout (2026-08-03, ~16h unbound). A 0.52.x bind gate refuses
re-bind when the perch record's dead session pid is RECYCLED onto a live process
(`CONFLICT:<id> is live under session <old>` in the adapter hook-trace.log) — the ABA class fixed
by `838eaeb` ([[pid-reuse-across-reboot]] mechanism), which first ships in v0.53.0.

**Why:** the deployah lockout was self-referential — deployah is the release agent, wedged by the
bug whose fix sat in the untagged release only deployah could publish. Manual unwedge was the only
exit.

**How to apply:**
1. Diagnose from the adapter's `hook-trace.log` (adapters/_github/SaberMage-claude-spt/), not the
   silent perch: `bind(startup) re-pin FAILED ... CONFLICT` is the tell. Transcript shape: hooks run,
   bridge banner, then nothing forever.
2. **Do NOT `spt endpoint purge`** even though the v0.53 refusal text names it as the escape:
   purge removes "every record keyed on it," and on HFENDULEAM **alchemy-0's shell perch is NESTED
   under `owlery/deployah/shells/`** — purge would destroy the board shell, plus the endpoint's
   message spool. Instead: kill the wedged launch tree (authenticate every node by cmdline `--id`),
   back up `info.json`, then atomically clear `session_id` to `""` and set `status: "offline"`.
   The conflict needs a non-empty mismatched session_id; an emptied one lets bind proceed and
   inherit the record. This corrects a FALSE record, not the enforcer — distinct from the refused
   stamp-version-mitigation shape.
3. **Relaunch via `spt endpoint run --adapter <a> --id <id> --create --start`** — NEVER by running
   `claude-spt.exe launch` from a shell: without a PTY, claude falls into `--print` mode and dies
   with "Input must be provided either through stdin or as a prompt argument". The daemon/broker PTY
   is load-bearing.
4. Verify: `status: online` in info.json, new ordinal in `sessions.log`, and a test `spt send`
   returning SENT (not QUEUED).

Retire this memory once every fleet node's **RUNNING BROKER image** is ≥ v0.53.0 — the gate then
reads the recycled pid as `Gone` and the lockout cannot form. **Installed version is NOT the
predicate** (deployah measurement 2026-08-04): the bind gate lives in the network layer, and a
daemon keeps its boot-time broker image for its whole life — hfenduleam measured installed 0.53.0
but running broker 0.52.0, still lockout-capable. Only a daemon restart lifts the broker; confirm
retirement from `spt daemon status` broker-image lines per node, never from install sweeps.
Roll scope RE-RULED 2026-08-04 (operator, via deployah): only SPT_DEV nodes are involved in spt
R&D — the fleet is HFENDULEAM + KITSUBITO for roll purposes; other nodes' versions are their
operators' business. Retirement predicate = BOTH SPT_DEV nodes at running broker ≥0.53.0.
Progress: kitsubito ROLLED to 0.53.0 (2026-08-04); hfenduleam DEFERRED — a HOSTED ENDPOINT CAN
NEVER BOUNCE ITS OWN NODE'S BROKER (`UPDATE_FINISH_REFUSED`, $OWL_SESSION_ID guard, no flag
overrides, and the refusal EXITS 0 — script trap). Its cutover needs a plain non-endpoint
terminal (human hands). The 2026-08-04 split-pair twohost guard was imposed then LIFTED same day
(temp-home rigs + in-job built pair; resident broker never in the twohost path) — do not
re-derive it.