Messages sent to Codex pairing pane

[lionello]

Codex has a daemon mode, but this means that sending messages to Codex daemon session tmux session doesn't arrive where it's supposed to:

────────────────────────────────────────────────────────────
  agent-box: codex Remote Control daemon is running.
  This pane is not a codex prompt — it signs the box in and pairs it.
  Machine name in the Codex apps: box.nixos.defang.ca
────────────────────────────────────────────────────────────

  ✓ Pairing code: WECP-XXXX
    Enter it in the Codex desktop or mobile app to adopt this box
    ("box.nixos.defang.ca"). Codes expire quickly — press Enter here for a
    fresh one. Already paired? Nothing to do; ignore this code.

  [Enter] fresh pairing code   ·   [type: login] sign in again

/rename claude@box.nixos.defang.ca: Azure VM UDP

We'll have to find another way to communicate to these remote Codex sessions. Note that regular/interactive Codex sessions would have received the command fine, but the Codex daemon pane needs special handling, because it might actually be hosting multiple Codex sessions and not only can't we use simple tmux for messaging, we'd have to communicate to the right session too.

[defangdevs]

Triage: this is a real gap, not a one-line fix.

Root cause, from modules/src/codex-remote-control.sh: a codex session with
remoteControl: true runs the pairing wrapper as its foreground process, not
a codex conversation. The wrapper starts codex app-server daemon, prints the
pairing code, and then just waits — any actual conversations that a paired
desktop/mobile client opens live inside that detached app-server process's
own session model, with no tmux pane of their own at all. So any
mechanism that delivers a message by resolving a session to a tmux target and
typing into it (a webhook delivery peer, agent-box-session add --prompt, one
agent messaging a peer via ListAgents/SendMessage) will, for a daemon-mode
codex session, land on the pairing screen no matter which of the daemon's
live conversations the sender meant — because none of them are addressable as
a pane. It's not that we're picking the wrong pane; there isn't a right one.

This is now more likely to bite: #625 turned the daemon into an explicit,
separate pick ("codex remote control (pairing daemon, no profile)") rather
than removing it, so it's a session shape that persists on boxes where
someone wants phone/desktop pairing. See also #504/#574/#623 for how much the
daemon-vs-TUI default has already moved — this is a related but distinct
question: not "which one starts by default" but "how do you ever reach a
specific conversation living inside the daemon once it exists."

Two directions, not mutually exclusive, and I don't think either is a quick
PR without a decision:

1. Cheap safety net now: teach tmux-target delivery paths to recognize a
   remoteControl: true codex session and fail loudly ("this session is a
   pairing daemon, not a conversation — message its clients directly")
   instead of silently typing into the pairing pane. Bounds the damage; does
   not solve reachability.
2. Real fix: find out whether codex's app-server JSON-RPC exposes
   enumerating its live remote-controlled sessions and injecting user input
   into one by id. If it does, agent-box's messaging primitives could target
   daemon-session:<id> instead of a tmux pane. If it doesn't, this is a
   capability gap in codex itself and belongs in an issue against it, not
   agent-box.

Leaving this open rather than turning it into a PR — which of the two (or
whether #2 is even possible against today's app-server protocol) is Lio's
call.

[lionello]

1. Cheap safety net now: teach tmux-target delivery paths to recognize a
   remoteControl: true codex session and fail loudly ("this session is a
   pairing daemon, not a conversation — message its clients directly")
   instead of silently typing into the pairing pane. Bounds the damage; does
   not solve reachability.

do this now so we don't send messages into the void @defangdevs

[defangdevs]

Opened #693: safety net direction 1 (fail loudly / skip instead of silently typing). agent-box-spot-monitor's notify_user() is the one delivery path in this repo that resolves a session name to its tmux pane and types into it directly (any harness); it now recognizes a codex remoteControl session and skips it with a logged reason instead. Direction 2 (a real per-conversation target inside the app-server, if codex's JSON-RPC exposes one) is still open and undecided.

[defangdevs]

Correction to my comment above: PR #693 does NOT fix this issue. Lio caught it in review -- spot-monitor is EC2-Spot-only (services.agent-box.spotInterruption.enable) and never runs on an Azure box, so it isn't what put that /rename line into the pairing pane here. I found a real instance of the same class of bug in spot-monitor and I'm keeping #693 open as a standalone hardening fix for EC2 boxes, but this issue's actual cause is still unidentified -- I don't yet know which mechanism delivered that message. Still investigating.

[defangdevs]

Update: found a concrete, verified bug that's a strong candidate for the real mechanism. AGENTS.md's documented self-rename fallback (if $TMUX_PANE is empty, find the pane with tmux list-panes -a -F '#{pane_id} #{pane_current_command}') can't actually discriminate between sessions on this box -- every pane reports bash as its current command (verified live), including the codex RC daemon's. An agent whose own $TMUX_PANE was empty and fell back to that recipe could land on any pane, codex's included. tmux display-message -p '#{pane_id}' reliably returns the caller's own pane with no guessing (verified with $TMUX_PANE unset). Details and the open question (Lio, did I get it right?) are on PR #693's review thread. Proposing this as a follow-up fix pending confirmation.

[defangdevs]

Opened #694: replaces the shipped guide's broken self-rename fallback (tmux list-panes -a + guessing by pane_current_command, which cannot discriminate sessions on this box -- verified live, every pane reports bash) with tmux display-message -p '#{pane_id}', which resolves through $TMUX with no guessing. Confirmed with @lionello in PR #693's review thread before opening this.