Remote send gate silently drops messages to an attended Codex loop: pane-created sessions carry no readiness proof

[scgopi]

Split out of #272 / PR #275, which fixes the same gate for every daemon-created Codex session but cannot fix this one.

Equally broken before and after PR #275 — this path is genuinely untouched by it. Before, the gate looked for codex in the session's cmd=, and a pane-created session does have a cmd= (zmx records one for attach) but it is the wrapper /bin/zsh -i -l -c '<script>', past zmx's 256-byte cap, so it arrives as cmd=/bin/zsh -i -l -c... and never matched either. After, the gate looks for an agent= label the pane does not write. Same outcome, different reason.

What happens

node send and message-edge delivery to a remote, attended Codex loop silently do nothing. No error, no queue, no retry — ZmxSessionLauncher.sendRemote gates the send on aliveCheckCommand, and for a Codex node that check demands proof the session is running Codex:

aliveCheck && { send && submit }

Why this path is not covered

GhosttyTerminalView.defersCodexLaunchToDaemon is true only for goalBased and timeBased loops. A turn-based or sketch Codex loop is launched by the pane, with zmx attach <name> <agent argv> — so the daemon's ensure never runs for it, and the ensure is the only thing that writes the agent= label PR #275 introduced.

Codex loop	Session created by	Stamped?	Remote send gate
goal / time-based	daemon ensure	yes	works
turn-based / sketch	pane attach	no	silently drops

Fix directions

• Stamp pane-created sessions. The pane launched the agent itself, so it has the same positive proof the daemon has — it can run zmx set <name> agent=codex alongside the attach (as a separate command, not inside the typed argv, which is where MAX_CANON bites — see Multi-KB --goal text is silently truncated by canonical-mode tty (MAX_CANON) at launch #57 and the note in agentLabelCommand).
• Or narrow the send gate: an attended loop's session is not the daemon's to relaunch, so the send could fall back to the name-only check for nodes the pane owns. Weaker, since it re-admits the bare attach shell for that case.

The first is the honest one and mirrors what the daemon already does.

Scope note

Local sends are unaffected: they check sessionExists rather than this gate.

[scgopi]

Cross-reference from #281 (Artifactory unreachable from remote/Codespaces loops), so the overlap is on the record and neither issue absorbs the other.

The two touch at exactly one point and nowhere else. #281's artifactory watch delivers its ding through wakeArtifactoryWatchers (GraphStore.swift:1644), which rides deliverAdHocMessage(…, followUp: true) — the same transport graphcode node send --follow-up uses. So a remote watcher hears its mail exactly as reliably as it receives a node send, which is precisely what this issue is about for attended (turn-based / sketch) remote Codex loops.

Consequences, stated so neither side waits on the other:

• Artifactory is unreachable from remote/Codespaces loops: the briefing teaches five verbs the shim refuses #281 does not fix or worsen this. Its work is confined to the delivered Python shim in RemoteGraphAccess.swift; it touches no send path, no readiness gate, and no session launch.
• This issue does not block Artifactory is unreachable from remote/Codespaces loops: the briefing teaches five verbs the shim refuses #281. Four of the five verbs — post, sync, read, list — are pull, not push: they work over the forwarded socket regardless of whether a session was ever stamped. Only watch dings are affected, and only for the loops this issue already names.
• Landing this makes watch complete for those loops with no further change in Artifactory is unreachable from remote/Codespaces loops: the briefing teaches five verbs the shim refuses #281.

🤖 Generated with Claude Code

https://claude.ai/code/session_013DBjXgnZNbVfUrxEo61z2r