basquetWi + New ticket
llmmsg-srv MSG-412

Codex push: codex queue + hub ack replaces send-keys nudge (scr-agent-inbox-nudge.py v1.4)

Backlog normal unassigned

SHIPPED to the live venus file 2026-09-20, NOT committed. Elazar CLI directive. sh.git = bin-venus-cc lane; flagged and proceeded. What changed: scr-agent-inbox-nudge.py v1.4 adds queue_push(), tried before safe_send(). Resolve the codex pid behind the pane, take the thread UUID from its open rollout fd (that fd is also the loaded-session proof required by the audit), GET /unread?agent= for the payload, render byte-compatibly with the shim's formatChannel, codex queue --thread U --message=<payload> (equals form: clap rejects a value starting with --), then ack the highest id actually pushed via GET /unread?agent=X&ack=<id>. Kill switch CCM_CODEX_QUEUE=0. Cap CCM_CODEX_QUEUE_MAX_CHARS=100000 for the 128KiB argv limit. Fail directions: no codex process / session not loaded / payload too large / queue rc!=0 -> False, nothing acked, old send-keys path runs unchanged. Queued-but-ack-failed -> True, so the next tick re-pushes: duplicate, not loss. Composer, BUSY_MARKER and pane_in_mode gates are skipped on this path by design - they exist because keystrokes need a live composer; a queued message does not. PERSIST_SECS, COOLDOWN, mid_gitdeploy still apply. Verified end to end on venus against test-llmmsgsrv-ca (pid 1158922, thread 01a0bcab-c1f3-7e41-b829-ca2fa756a509): pid resolved, UUID resolved, payload rendered 714 chars, queued rc=0, acked to 128360, agent received and replied. Timer healthy on v1.4 (clean 10s exits, no errors). py_compile clean. Audit conditions honoured: loaded sessions only; payload carries a provenance trailer naming the hub, because a queued message is indistinguishable from human typing (test-llmmsgsrv-ca attributed an earlier one to Elazar). Known hazard: format_channel() in the .py is a SECOND implementation of the shim's renderer. If either drifts, agents see two different inbox formats and nothing fails. Open: commit + gitpush.sh --only (bin-venus-cc coordination, then whey/lezama pull); standing audit DM. Findings: /data-venus/llmmsg-srv/findings/2026-09-20-codex-push-and-inline-body.md

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 3w ago
  • wi-cli-venus note · 3w ago
    Deployment state, recorded separately from the hub (coder-llmmsgsrv-ca's correction). HUB: llmmsg-srv-venus.service restarted 2026-09-20 03:55:05 UTC on 2.60.0 (MSG-414) - that restart deploys NOTHING of MSG-412. SHIM: still pending. Activating MSG-412 in a running session needs scripts/install-mcp-shim-runtime.sh from commit 5d1d920 or later, the runtime version read back as >=2.59.27, and the affected Codex sessions restarted - a hub restart cannot reach an already-spawned shim. SCRIPT: scr-agent-inbox-nudge.py v1.4.2 is installed live on venus (md5 8d75fdc33a654240acce3b8f42154c8c) and the timer is green on it, but it is still UNCOMMITTED - bin-venus-cc's lane holds commit 17f2c34 (v1.4) unpushed, which predates the v1.4.1/v1.4.2 audit fixes (codex_agent_name attestation gate from /proc/<pid>/environ, single-rollout-fd thread_uuid, rewritten docstring, trailer). Open: bin-venus-cc commits+pushes, then whey/lezama pull.
  • wi-cli-venus note · 3w ago
    Shim deployment completed on both remote hosts 2026-09-20, hub 2.60.0 / commit d19ea9f. CRITICAL TOPOLOGY FACT, previously wrong in my own reporting: whey and lezama do NOT execute the shim from /opt/llmmsg-srv. Both point ~/.claude.json llmmsg-srv at ~/.local/lib/llmmsg-srv/current/hub/llmmsg-srv-mcp.mjs, a pinned versioned release tree. A git pull plus a session restart on those hosts deploys NOTHING; scripts/install-mcp-shim-runtime.sh --expected-commit <sha> is the deploy step, and it stages releases/<version>-<sha12> then atomically repoints 'current'. Venus is the exception and does run from /opt, which is why pm-llmmsgsrv-cc came up on 2.60.0 immediately after respawn with no install step. State now, three numbers per host, and the third only moves on relaunch: lezama checkout 2.60.0 / symlink 2.60.0-d19ea9fc4900 / running 2.59.21. whey checkout 2.60.0 / symlink 2.60.0-d19ea9fc4900 / running 2.55.1 - whey's running shims were already 4 minor versions behind its own checkout BEFORE this pull, so that drift predates MSG-414 and was invisible because the hub only ever sees the running version. Old release dirs are intact on whey (2.47.19, 2.47.20, 2.55.1), so rollback is a symlink flip. Installer gotcha worth keeping (bin-whey-cc): git -C /opt/llmmsg-srv status --short --untracked-files=no prints root-owned agents/ Permission denied lines to STDERR. The dirty-tree guard at install-mcp-shim-runtime.sh:37 captures stdout only, so it is unaffected - do not read those lines as a dirty tree and abort. Remaining: Elazar relaunches panes by hand; no agent restarts another agent's session. Until relaunch, MSG-412's Codex queue push is inert in every running -ca session. bin-whey-cc is drafting a global CLAUDE.md amendment to nw-whey-cc covering the deploy-authority change and this release-tree topology.
task
3w ago by wi-cli-venus
3w ago