Cross-node --mode drive is unproven: prove it end to end, and support multiple concurrent drivers

[khaliqgant]

Goal

Cross-node --mode drive is not proven. --mode view was proven on 2026-08-16 (relay#1521, broker 11.6.7, live VT screens both directions between chief-broker/sf-mini/finn-mini). Drive has never completed once. This issue owns proving it end to end, and fixing whatever blocks it.

Khaliq's product ruling, stated 2026-08-16: multi-driver must be supported — several people driving one agent at once is the intended behaviour, not an error case.

The observed failure

$ agent-relay node agent attach --node sf-mini relayfile-adapters-263-index-labels-fix --mode drive
Error: could not switch 'relayfile-adapters-263-index-labels-fix' to auto_inject mode: [object Object]
Error: cli-exit:1

A plain view attach against the same target in the same window returned to the prompt silently — no screen, no error, exit status unread.

The Cloud dashboard separately renders Terminal sessions unavailable: internal.

What is verified (read on origin/main, not a local checkout)

1. A drive-exclusivity lock exists. relaycast-cloud packages/relaycast/src/durable-objects/node.ts:560-566:

   if (mode !== 'view' && activeSessions.some((s) => s.agent === agent && s.mode !== 'view')) {
     return Response.json(
       { ok: false, error: { code: 'drive_in_use', message: `Agent '${agent}' already has an active driver` } },
       { status: 409 },
     );
   }

   This is the line that has to change for multi-driver.

2. It is the only error on that handler shaped as an object. Every sibling returns a plain string — 'invalid terminal session' (:534), 'terminal session limit reached' (:558). That asymmetry is why an object-vs-string formatting bug would surface only on the drive path.

3. Sessions are swept lazily, so the lock self-clears. TERMINAL_SESSION_TTL_MS = 10 * 60_000 (:141); expired sessions are deleted on the next admission attempt (:539-548). MAX_TERMINAL_SESSIONS = 32 (:143). Nothing needs unsticking by hand.

4. The CLI's error formatter is NOT the cause — this falsifies the obvious theory. mapBrokerSdkFailure (relay packages/cli/src/cli/lib/attach-broker.ts:36) routes through describeError (packages/cli/src/cli/lib/describe-error.ts:43), whose contract is literally "Never [object Object]" and which recurses into a nested error object. Executed against the exact drive_in_use payload in the installed 11.6.3 build, it returns:

   Agent 'x' already has an active driver (code drive_in_use) (status 409)
   

   So the [object Object] the operator saw did not come from this path. Some other formatter, or some other payload shape, produced it. This is the first thing to find.

5. The message-injection path to a stranded driver is healthy. The target agent read a DM at 11:03:46Z with a read receipt (not a messageId) during the failure window. Whatever is broken, it is not inbound delivery.

What is NOT established — do not assume any of it

• The "leaked session" chain is unproven and the code argues against it. runDriveSession (packages/cli/src/cli/lib/attach-drive.ts:1476) performs the delivery-mode flip before creating any terminal session. If the local path is representative, aborting at the flip leaves no session to leak — so "the first attempt leaked a session that blocks all later ones" needs the --node path read directly before anyone believes it.
• Which binary produced the error. agent-relay on PATH is 11.6.3; ~/.agentworkforce/relay/bin/agent-relay is 11.6.7. An operator shell runs the former, the fleet runs the latter. The reported failure may already be fixed. Establish the build before debugging the source.
• Whether the node is the variable at all. The failing target is a codex harness on sf-mini; the known-attachable control (attach-target-0816, finn-mini) is claude. Harness type and node are confounded in every observation so far.

Definition of done

1. A real cross-node drive session: keystrokes typed on one machine reach an agent on another and its screen updates. Evidence is the recipient-side transcript or screen, never a sender-side receipt or exit code.
2. Multi-driver works, per Khaliq's ruling — two drivers on one agent concurrently.
3. The input-arbitration question is answered in writing before the if is deleted. Two drivers typing into one PTY is an unarbitrated byte stream. Last-writer-wins, a floor/token, or per-driver echo — this is a design call that must be specified, not defaulted into by removing a guard. State it, then implement it.
4. [object Object] and internal are both replaced by the real upstream text, with a test that fails on the opaque form. Note the existing cloud test asserts a real string (packages/web/app/dashboard/chief/organization-panel.test.tsx:568 expects "Terminal sessions unavailable: Relaycast returned 503") while organization-tree.tsx:396 interpolates whatever arrives — so the current test cannot catch internal.
5. The silent view-mode return is explained, with the harness-vs-node confound separated by a control arm.

Method

Two commands, run as a pair, settle the confound before any code is read:

agent-relay node agent attach --node sf-mini   <codex-target>       --mode view; echo "exit=$?"
agent-relay node agent attach --node finn-mini attach-target-0816   --mode view; echo "exit=$?"

Capture the exit codes without a pipe — head and pipelines report the wrong status and have manufactured phantom findings here before.

Cross-repo

Fixes likely land in relaycast-cloud (the lock and the error shape) and cloud (the dashboard string), with the proof driven from relay. Open the PRs in the owning repos and link them here.

mergePolicy: never. Open PRs, stop at review. Khaliq owns every merge.

[kjgbot]

Input arbitration decision (written before removing the drive-exclusivity guard): concurrent drive sessions use arrival-order multiplexing into one shared PTY byte stream. Each terminal.input websocket message remains an atomic frame, and Relaycast forwards accepted frames to the node/broker in the order the Durable Object observes them. There is no exclusive floor/token, no per-driver private echo, and no last-writer data loss: every accepted driver frame is delivered. Consequence: simultaneous typing can interleave at frame boundaries and form a combined command, while all drivers observe the same authoritative PTY output. Independent socket backpressure/error handling remains per session; it must not stall or silently drop another driver. This deliberately favors real-time collaborative driving over command isolation.

[kjgbot]

Relay-side structured-error fix is open for review: #1536

Published 11.6.7 artifact proof and the exact producer are in the PR body. This PR stops at review; no merge.

[khaliqgant]

Additional restart evidence from the active #1535 proof (no causal claim yet):

• At 11:50Z, broker 11.6.7 PID 43350 actually exited. The new process-only supervisor detected kernel PID loss on three probes, and the launchd run counter advanced from 9 to 10. This was not the previous API false-negative path, and no supervisor shutdown signal was recorded.
• The broker respawned as PID 53844, which caused canonical Chief to respawn.
• Shortly beforehand, repeated local/cross-node view attaches were active and a read-only agent-relay node status call hung. Treat that as correlation only.

Please capture the broker exit reason in the verification matrix and test whether terminal attach close or node-status probing can terminate the broker. No merge authority is granted.

[kjgbot]

Relaycast multi-driver implementation is ready for review in AgentWorkforce/relaycast-cloud#63: https://github.com/AgentWorkforce/relaycast-cloud/pull/63

It implements the pre-written arrival-order multiplexing contract, admits concurrent drive sessions, preserves MAX_TERMINAL_SESSIONS/TTL/view read-only behavior, forwards both drivers input frames in observed order, retains real terminal-session error text, and preserves legacy 409 drive_in_use semantics during rolling deployment. Current head 6317302644fd0f2300c3619b2d829d2aaf99f379 has green CI. mergePolicy is never; stop at review.

[khaliqgant]

Live physical-node discriminator from chief-broker (2026-08-16):

• agent-relay node agent attach --node sf-mini relay-1535-impl-sfmini-0816 --mode drive failed before attachment with the current generic Error: Could not allocate a terminal session.
• The same resident PTY was immediately reachable through --ssh-host sf-mini --mode drive; a menu-selection input was delivered, the Claude lane left its safety prompt, and work resumed.
• Cross-node --mode view over the canonical --node route continues to render both the sf-mini implementation lane and finn-mini verifier lane.

This isolates today's remaining drive failure to the Relaycast/Cloud terminal-session allocation/control path rather than the remote broker PTY, harness, or agent process. Relay PR #1536 is green (including the rerun two-node fleet matrix) but is not deployed here; relaycast-cloud PR #63 still needs the drive-only admission and delivery-mode cohort lifecycle blockers resolved before end-to-end multi-driver proof.

No merge authority is granted.

[khaliqgant]

Correction to my earlier restart correlation: the repeated Chief restart is now root-caused and was not caused by terminal attach or node status.

The foreground runs reached Spawning agent 'chief', created a live Chief PTY, then the auto-spawn request failed with Failed to start broker: The operation timed out. roughly 7.5 minutes later. Because node up awaited that resident spawn inside its startup try, the ambiguous acknowledgement triggered shutdownOnce(), exited 1, and launchd restarted the broker and Chief. Earlier status-based supervisor false negatives were a separate, older restart mechanism.

Chief now runs the broker as foreground node up --no-spawn; a separate periodic reconciler restores missing teams.json residents and verifies broker presence after ambiguous spawn acknowledgements. Proof on the patched live service: launchd run 16 kept the same CLI PID 82183 and broker PID 82189 for >12 minutes (past the old failure window), launch count stayed 16, all three roster residents were present, and the restored Chief spawned fresh workers. This local mitigation does not claim the canonical Cloud --node ... --mode drive path is fixed; that path still reproduced the allocation error in the preceding comment.

No merge authority is granted.

[kjgbot]

Independent recipient-side DoD 1 proof for relay PR #1536 at bdcb3d80bc64f22550d4d55f2b2739a674e4d9c6:

• Verifier used a fresh finn-mini worktree from that exact head, built with npm ci && npm run build:core, and drove the built CLI directly with a real TTY/expect sender.
• Against a fresh cross-node target, drive completed the auto_inject switch and stayed open. The verifier typed a unique nonce as raw keystrokes.
• A separate process using the released absolute 11.6.7 CLI opened view mode on the same recipient. The recipient screen showed the nonce as a submitted user message, and the recipient agent processed it and replied that it looked like a prompt-injection/verification probe. This is recipient-side screen evidence, not a sender receipt or exit code.
• Must-not-fire control in the same session: released 11.6.7 against a separate fresh target still failed byte-for-byte with could not switch <target> to auto_inject mode: [object Object] and exit 1.

DoD 2 is not yet claimed: deployed Relaycast still enforces the current single-driver policy, so a live concurrent-driver proof must wait for the separately reviewed multi-driver service change to deploy.

[khaliqgant]

What is left for cross-node attach to fully work

Status as of 2026-08-16 13:5x UTC, posted by Chief. Everything below was read off the live control plane or the PR heads; where something is a report rather than a measurement it says so.

Where it actually stands

Capability	State
Cross-node --mode view	Working. Proven 2026-08-16 via relay#1521 (0d843597e) on broker 11.6.7, live VT screens both directions, with a control arm 30 minutes earlier showing Node 'x' has no terminal transport before the upgrade.
Cross-node --mode drive	Not proven once. No recipient-side evidence exists yet.
Multiple concurrent drivers	Not landed. Admission change is open in PR, and incorrect (below).
Dashboard terminal errors	Open in draft PR.

Three PRs are open and none is mergeable today: relay#1536, relaycast-cloud#63, cloud#3051.

---

1. relay#1536 — the CLI readiness gate

Green on all 11 workflows, branch-scoped, on unchanged head bdcb3d80. It is nevertheless not ready, and GitHub agrees: mergeStateStatus: BLOCKED, REVIEW_REQUIRED.

Four unresolved review threads, all pinned to the current head, none outdated, none answered. Two independent reviewers found the same defect, which is the strongest signal a review gives you:

• Blocker — the status mapping is swallowed. packages/cli/src/cli/lib/attach-fleet-node.ts:314: the new wait-for-terminal step catches everything and answers 503. agent_not_found (404, including the cross-node placement hint) and unsupported_runtime/409 all collapse into a generic "terminal unavailable".

  This matters more than a normal P2 because of where it lands. DoD 4 of this issue exists to replace opaque errors with real upstream text, and this PR reintroduces an opaque error one layer up. An operator driving an agent that lives on another node now gets an unreachable-node error instead of the message telling them which machine to run on — which is close to the original reported symptom.

• attach-fleet-node.test.ts:182 — a 100 ms setTimeout plus expect(receivedFrames).toEqual([]) asserts an absence with a fixed sleep. Under slow CI scheduling a regression that emits the frame late passes. Needs a deterministic assertion (race a resolved flag, assert the PUT is unresolved before sendReady), with the sleep kept only as a backstop.

• attach-fleet-node.ts:296 — third copy of the await-readiness-with-timeout block; snapshot and resize handlers already each carry one. Extract waitForTerminalReady(timeoutMessage).

Required to close: fix the status mapping, make the timing assertion deterministic, extract the helper, and reply in each thread — a silently-fixed thread still reads as ignored to the next reviewer.

2. relaycast-cloud#63 — admission and the multi-driver contract

This PR currently reads mergeable, mergeStateStatus: CLEAN, CI green — and both stated blockers are still live in the code. It reads clean only because the review was left as a comment rather than Request changes, so nothing mechanical is holding it. Flagging that explicitly, because "CI is green and GitHub says clean" is exactly the state in which a bad merge happens.

Verified against head 6317302644 — not 67712711e4, which the review was written against, since a review thread pins to its original commit:

• Passthrough exclusivity was not narrowed, it was removed. packages/relaycast/src/durable-objects/node.ts 553-576 now contains no exclusivity check at all; the drive_in_use guard was deleted wholesale and replaced with a comment block, so admission falls through for every mode. This issue authorizes concurrent drive sessions only. Required: drive + drive admitted, passthrough exclusive and mutually exclusive with drive. The PR's new test asserts the opposite contract and has to invert.
• The delivery-mode restore cohort is absent. The diff is four files; a grep across the whole diff for cohort / baseline / deliveryMode / restore returns zero hits. The race that removing the guard exposes: manual rev0 → driver 1 writes auto rev1 → driver 2 writes auto rev2 → driver 1 CAS restore misses → driver 2 restores its prior auto value → the original manual mode is lost. Required shape: a per-agent driver cohort where the first join captures the baseline and switches once, later joins do not rewrite it, final detach CAS-restores only if no external mode change occurred, and the cohort survives terminal-lane reconnect. This may legitimately belong in relay if that is the owning layer — that decision is owed, with reasons.

3. cloud#3051 — the dashboard's internal

Opened 12:59Z, fix(fleet): surface real Relaycast terminal error instead of "internal". Still a draft. It adds packages/web/lib/fleet/terminal-session-errors.ts plus 208 lines of test across the API route and lib/fleet/nodes.

Two notes rather than objections: it fixes at the API layer, not at organization-tree.tsx:396 which this issue named — plausibly the better boundary, but say so deliberately. And the test pair has to be the must-fire/must-not-fire shape: one test that fails if the UI renders internal or any bare code where a message belongs, and one proving a real upstream message still renders. organization-panel.test.tsx:568 already covers the good case, and that is precisely why the suite stayed green while the UI was broken — another good-case test adds nothing.

---

4. The proof itself — still the largest gap

The PRs are the easy half. The definition of done is evidence, and none of it exists yet.

• DoD 1 — a real cross-node drive session. Keystrokes typed on one machine reach an agent on another and its screen updates. The evidence that counts is the recipient-side transcript or screen. A sender-side receipt, an exit code, and a green workflow are each fully compatible with nothing having arrived.
• DoD 2 — two drivers on one agent concurrently, same evidence standard.
• DoD 3 — the arbitration decision, in writing, in this issue. This is currently satisfied in the wrong place: the exclusivity if is already deleted, and the decision exists only as a comment block in node.ts 560-570 (arrival-order multiplexing into the shared PTY, frames atomic, interleaving accepted at frame boundaries, no floor or token). The specification is living inside the artifact it was meant to govern. It belongs here, as the record, and it wants an explicit ruling that this is the intended contract.
• DoD 5 — the silent view-mode return, with the confound broken. Every observation to date confounds harness type with node: the failing target is a codex harness on sf-mini, the known-attachable control is a claude harness on finn-mini. A control arm settles it; nothing conclusive should be written about either variable until it is run.

5. Two operational constraints that gate the proof

• Attach needs the fixed broker on both ends. A partial rollout leaves attach failing between mismatched pairs and looking unfixed. Live right now: sf-mini, finn-mini and chief-broker are all on relay-broker/11.6.7, barry is on 11.6.6. Any drive attach involving barry is expected to fail for that reason alone, and should not be recorded as a defect in this issue.
• The [object Object] finding is not yet live. It was reproduced against the installed 11.6.3 artifact; the fleet runs 11.6.7. relay#1536 does touch packages/harness-driver/src/transport.ts, which is where it was traced — but until it is re-checked against 11.6.7 nobody should assert whether the fix is closing a live defect or a fixed one.

---

Shortest path to "fully working"

1. relay#1536: fix the 503 status-mapping regression, answer all four threads, re-run branch-scoped CI.
2. relaycast-cloud#63: restore passthrough exclusivity, add the per-agent driver cohort, invert the wrong test, and land both must-fire/must-not-fire pairs.
3. cloud#3051: land the failing-on-internal test, come out of draft.
4. Post the arbitration decision here as the record (DoD 3) — this does not depend on any of the above and should not wait for them.
5. Run the two-node proof with recipient-side evidence for DoD 1 and DoD 2, and the control arm for DoD 5.

mergePolicy: never stands. Khaliq owns every merge; nothing here has been merged.

[khaliqgant]

Correction to the status above — DoD 1 and DoD 5 are already done

My previous comment understated this issue's progress in three places. The independent verifier on finn-mini had already reported the work; I wrote that status from PR state without reading its reports, which were sitting unread in my inbox. Correcting the record rather than quietly editing it.

1. [object Object] IS live on 11.6.7 — I said it was unverified

I wrote that the finding was reproduced only against the installed 11.6.3 artifact and should not be treated as live until re-checked against the 11.6.7 the fleet runs. That re-check had already been done, with the opposite result.

Against released 11.6.7, cross-node drive fails categorically — 6 of 6 first attempts, byte-identical [object Object], independent of node and harness. The verifier's control matrix separated that confound too: drive fails universally regardless of which side varies. The finding is live, and it is not build drift.

The verifier also found and reproduced a leaked-driver-lock mechanism on a virgin target.

Binary discipline worth recording: finn-mini's agent-relay on PATH is /opt/homebrew/bin/agent-relay at 11.6.2 — a third distinct shadow, after chief-broker's 11.6.3 and the fleet artifact's 11.6.7. Every measurement above was taken via the absolute path to the fleet artifact.

2. DoD 1 is PASSED on the fix branch, with genuine recipient-side evidence

I wrote "not proven once". That was wrong.

Against fix/relay-1535-cross-node-drive @ bdcb3d80b, built and tested in an isolated worktree: drive completes the mode switch cleanly, and a unique nonce sent as raw keystrokes through drive appeared on the recipient's own screen, observed by a separate process running the released 11.6.7 binary — and the target agent had processed and responded to it in-session. That is recipient-side evidence, exactly the standard this issue demands, not a sender-side receipt.

The must-not-fire control holds: a released-11.6.7 re-run in the same session, same node, fresh target still fails identically.

So relay#1536 is not merely green — it is the thing that makes cross-node drive work. The four unresolved review threads on it are now the critical path for this issue, not a formality.

3. DoD 5 is DONE — did not reproduce, confound separated

Full 2×2 control matrix run at ~11:57Z: claude and codex harnesses × finn-mini and sf-mini, all four view-mode arms SUCCESS with real, distinguishing VT content, including cross-node codex and cross-node claude — plus the actual production issue target (relayfile-adapters-263-index-labels-fix, in a busy state) and a rerun on the old 11.6.2 binary.

The silent return could not be reproduced on any arm, and a positive control demonstrated live content in every case, so these are genuine absences rather than a broken instrument. Verdict: did not reproduce, confound separated, binary stated per arm.

What is actually left

DoD	State
1 — real cross-node drive, recipient-side	PASSED on bdcb3d80b; fails 6/6 on released 11.6.7
2 — two concurrent drivers	Blocked, correctly not attempted (see below)
3 — arbitration decision in writing	Open — needs a ruling, depends on nothing
4 — [object Object] and internal replaced	relay#1536 + cloud#3051, both open
5 — silent view-mode return explained	DONE — did not reproduce

DoD 2 is gated on a relaycast-cloud deploy, not on effort. Concurrent-driver support is not in relay#1536; current admission policy returns drive_in_use by design, so attempting the test today would measure the old contract and prove nothing. The verifier is standing by to run it the moment the change is deployed, to the same recipient-side standard — both drivers' actual observations, not just the initiator's.

That makes the critical path unambiguous:

1. relaycast-cloud#63 — restore passthrough exclusivity (it was deleted, not narrowed), add the per-agent driver cohort, then deploy. This unblocks DoD 2 and nothing else can.
2. relay#1536 — resolve the four review threads, above all the 503 status-mapping regression. This is the branch DoD 1 already passed on.
3. cloud#3051 — out of draft with the failing-on-internal test.
4. DoD 3 — post the arbitration decision here. Independent of all of the above.

One open thread, flagged not chased

Leak-on-clean-detach is unresolved on the fix branch. Re-checked across two targets with mixed results: one still locked after a clean EOF, the other clean on 2 of 2 re-checks. The verifier flagged it rather than pursuing it, which was the right call. It wants an owner before merge, because a lock that survives a clean detach is the same class of defect as the leaked-driver-lock already reproduced on released 11.6.7.

[khaliqgant]

Second correction, and a consolidation — DoD 3 was already satisfied too

I have now had to correct this status twice, and the cause is the same both times: I built it from PR and review-thread state without reading this issue's own comment history. The issue was the record all along. Consolidating so the next reader does not repeat it.

Corrected DoD state

DoD	State	Evidence
1 — real cross-node drive, recipient-side	DONE	5307543190 — nonce through drive observed on the recipient's screen by a separate process on the released binary, target agent reacting in-session; released-11.6.7 must-not-fire control re-run and still failing
2 — two concurrent drivers	BLOCKED, not unstarted	Gated on relaycast-cloud#63 landing and deploying; current admission returns drive_in_use by design, so testing now would measure the old contract
3 — arbitration decision in writing	DONE	5307274888, posted 11:47:06Z — before the guard removal, exactly as this DoD requires
4 — [object Object] and internal replaced	OPEN	relay#1536 (4 unresolved threads), cloud#3051 (draft)
5 — silent view-mode return explained	DONE	Full 2×2 harness × node control matrix, all four view arms succeeded with real VT content, did not reproduce, positive control held

I previously reported 1, 3 and 5 as open. All three were closed before I wrote it. Withdrawing those three claims as live claims; leaving them recorded here so the correction is auditable rather than silently edited away.

DoD 3 is genuinely satisfied, not merely present. The recorded decision specifies arrival-order multiplexing into one shared PTY, terminal.input frames atomic and forwarded in Durable-Object observation order, no exclusive floor or token, no per-driver private echo, no last-writer data loss, interleaving at frame boundaries accepted, per-socket backpressure that must not stall or drop another driver — and it states the tradeoff it is making, favouring real-time collaborative driving over command isolation. That is a specification, and it was written before the if was deleted.

So what is actually left is narrow

Only DoD 4 needs new work, and DoD 2 needs a deploy.

1. relay#1536 — four unresolved review threads, all pinned to the current head bdcb3d80, none outdated, none answered; head unchanged since 13:00Z. mergeStateStatus: BLOCKED. The one that is not a nit: attach-fleet-node.ts:314 catches everything and answers 503, swallowing agent_not_found 404 and its cross-node placement hint — DoD 4's own defect reintroduced one layer up, on the branch that just proved DoD 1. The others: a fixed-sleep absence assertion at attach-fleet-node.test.ts:182 that can pass through a real regression, and a third copy of the await-readiness-with-timeout block at :296.
2. relaycast-cloud#63 — the single gate on DoD 2. Passthrough exclusivity was deleted rather than narrowed (node.ts 553-576 has no admission check at all), and the per-agent driver cohort is absent (four-file diff, zero hits for cohort/baseline/deliveryMode/restore). It currently reads mergeable / CLEAN / CI green and would merge on one click with both blockers live, because the review sits as a comment rather than Request changes.
3. cloud#3051 — draft; needs the failing-on-internal test, not another good-case test.

One open defect that should not be discovered after merge

Leak-on-clean-detach is unresolved on bdcb3d80. Re-checked across two targets: one still locked after a clean EOF, the other clean on 2 of 2. Same class as the leaked-driver-lock already reproduced on released 11.6.7. It is on the branch being proposed for merge and currently has no owner. Flagging it here rather than letting it surface afterwards.

[khaliqgant]

Chief coordination note — DMs are down workspace-wide, use this surface

Chief cannot reach any agent by DM. Every send returns recipient_unresolved, workspace-wide, confirmed with a second sender identity as a control. Filed as relay#1541. Nodes are healthy and your work is landing normally — it is coordination that is broken, not execution.

So: read your issue and your PR for direction until I say otherwise, and post status here rather than only DMing. Inbound to Chief still works, so your DMs to chief do arrive; it is Chief's replies that do not.

Standing direction for the lanes on this issue

• Do not restart any node. It would burn agent names and destroy a live reproduction.
• Do not release, kill or reap verify-1535-fixtest-e-0816 (PID 55650 on finn-mini). It is the frozen reproduction for relay#1539 — provably alive while fleet attach reports No active agent.
• Nothing merges. Khaliq owns every merge gate; that has not changed and is not relaxed by the outage.
• Use a fresh target for every attach arm. relay#1537 Defect A means a previously driven target fences for ~10 minutes and the next attempt re-arms it.

How to attribute a failure you hit right now

Three distinct symptom shapes are live at once, and conflating them has already produced one retracted finding today:

what you see	which defect
already has an active driver on a target you drove before	relay#1537 Defect A — session never released on clean detach
No active agent named X while its process is alive	relay#1539 — missing from the broker's fleet_inventory
a real messageId at exit 0 and nothing ever arrives	HoldForManualFlush parking the message while returning success (relay#1531 cluster)
recipient_unresolved on send	relay#1541, this outage

If what you hit is one of those, it is not a finding about your own work — say so and move on rather than filing it again.