Repository navigation
[#1268] Attach the editor to the durable hub over Remote-SSH — host-side adoption, never-fork at the handshake seam #1270
Description
Important
Problem — The walking skeleton for ADR 0025: prove a VS Code Remote-SSH window can attach to the durable hub host and have the extension activate host-side against the running hub, without spawning a rival engine/store. This is the highest-risk seam — the extension's adopt-or-spawn engine path probes the canonical port, and an unrecognized handshake cold-spawns a second writer (the exact two-writer collision the durable-hub work warns about).
Approach — Open a Remote-SSH window onto the hub host (reusing the fleet's existing SSH host + key trust — the same the ssh transport already uses), let the extension relocate host-side, and assert it adopts the running durable-hub engine + service at the shared handshake rather than spawning. Produce a relocation audit (investigative output) recording, per surface — native Explorer, terminal, engine, service, runs, chat — host-correct or broken, to seed the later slices.
Scope — in: the attach path; the never-fork/adoption assertion at the canonical handshake; the relocation audit. · out: the opt-in UI (S2); window-mode surfacing (S3); the default flip.
Assumptions — the hub host is already an SSH target with key trust (inherited from the fleet ssh transport); the durable hub runs the runner engine + service.
Acceptance Criteria
- Opening a Remote-SSH window onto the hub host activates the extension host-side.
- The host-side extension adopts the running durable-hub engine and service at the canonical handshake/port — it spawns no second engine and no second store (never-fork; one canonical writer asserted).
- If the running hub does not present the adoptable handshake, the failure is explicit/surfaced, not a silent cold-spawn of a rival engine.
- A relocation audit is produced enumerating each surface as host-correct or broken (HITL review artifact).
Testing Decisions
Extend the durable-hub-service + adopt-or-spawn suites with a host-side-relocation adoption case (adopts the running engine at the handshake; no second engine/store; unadoptable → surfaced, not cold-spawn). The audit is a review deliverable, not a test.
Key Decisions
- Reuse the fleet's existing SSH host/key trust; introduce no new credential handling (that is Credential portability: take/push provider creds between client and hub over SSH #782, out of scope).
- Adoption at the canonical handshake is the never-fork guarantee — assert the seam, do not black-box "no second engine."
Constraints & Invariants
- Never-fork + one canonical writer (ADR 0005); loopback-only bind preserved (host binds
127.0.0.1; the Remote-SSH channel is the transport). - No silent fallback — an unadoptable hub is surfaced.
Prior Art
- The durable hub service + the runner; the adopt-or-spawn lifecycle + server handshake; the fleet
sshtransport (host/key trust); devcontainer/WSL relocation behavior.
Source
- Part of Remote-SSH as a first-class fleet posture (opt-in) — host-native tooling on the durable hub #1268 · design of record ADR 0025 · Blocked by: ADR 0025 acceptance.
Activity
fleet(#1270): prove host-side Remote-SSH relocation adopts the durabl…
fleet(#1273): prove single-writer across a thin-client ⇄ Remote-SSH m…