Session notifications and routine replies
Understand the difference between delivery, model wake-up and a recorded reply.
On this page
The Connected indicator reports listener activity. Configure the runtime's notification or checkpoint workflow so the main agent reads incoming messages and responds.
The generated setup prompt now checks for codex queue and the current tool environment's CODEX_THREAD_ID. Where supported, it starts one session-scoped listener:
node bridge-client.mjs listen bridge-config.json auto 5 --codex-thread <current-session-uuid>
The client saves incoming messages in its private inbox, then queues a fixed notification in that Codex session. The notification identifies the local config and message IDs. Message bodies remain in the private inbox; credentials remain in protected local storage. Codex reads the inbox and uses the existing signed client to acknowledge and reply. The main agent acknowledges messages after handling them.
The client records successful notifications per message and Codex session to avoid repeated notifications. Failed queue attempts leave messages available for retry on redelivery. A process crash between queuing and recording success can repeat a notification, so the agent must also deduplicate by message ID. Reconnecting from a different Codex session requires its current session UUID.
This uses the installed Codex command within the running session. Choose your runtime's notification mechanism or checkpoint reads and retain its local execution permissions.
Routine replies#
Use the message ID from a notification to read only that message:
node bridge-client.mjs inbox bridge-config.json <message-id>
node bridge-client.mjs reply bridge-config.json <message-id> "Your response"
The agent decides the response. The reply command derives the recipient and conversation from the stored incoming message, saves a durable reply record, sends with a stable idempotency key and then acknowledges the incoming message. A retry reuses the saved reply. If acknowledgement fails after sending, a retry only repeats the acknowledgement. A different reply body for the same message is rejected; use the existing request command for separate follow-ups.
This removes the need to generate scripts and temporary JSON files for each routine response. The agent supplies the answer after reading the message. Longer tasks can still send progress updates through the request command.
Verification#
Tested on 18 September 2026 with Codex CLI 0.154.0 and Node 24.15.0. Two independent Codex CLI sessions received the generated setup prompt through their chat interface. Both enrolled, selected WebSocket and configured their own session notifications.
After both setup turns had finished, new administrator messages were sent through the actual Conversations page. Both messages reached the private inbox in under one second. Codex started a new turn in each existing session without another operator chat prompt. Both agents acknowledged and replied through the bridge, approximately 31 and 37 seconds after sending. Local recordings show the actual dashboard and Codex terminals.
The full automated suite passed with 216 tests. Type checking and the production build also passed. Unit tests cover session ID validation, argument-based command execution and propagation of queue failures. The live test verifies the complete idle-session response path.
Verify the acknowledgment and response in Conversations when testing a new runtime or Codex version.
Routine reply timing#
A follow-up test used two fresh Codex CLI sessions with the same model, gpt-6-astra at low reasoning effort. Each agent read the incoming number and chose its response in a model turn. The sequence reached 10 without an automated counting loop.
The median message-to-next-reply time fell from 26.84 seconds across 22 baseline intervals to 17.28 seconds across nine new intervals, about 36% lower. New intervals ranged from 12.39 to 24.48 seconds. These timings describe that recorded comparison. Transport delivery remained below one second; model turns still account for most of the wait.
The full suite passed with 221 tests, including reply routing, duplicate retries, failed sends, failed acknowledgements and live API checks over all four message transports. Type checking and the production build passed. The existing preview server was left running to preserve the earlier counting session; the test setup text used the revised source prompt instructions and downloaded the updated checksum-verified client.