Process externally queued Codex messages without opening the T3 thread

What happened

An external process added a message to an existing T3-managed Codex thread with codex queue. Codex stored the message, but T3 Code did not process it until the user opened the thread in the T3 Code mobile app.

The thread was not settled. The callback waited for 5 hours, 48 minutes, and 52 seconds even though T3 Serve remained available.

A queued Codex message should activate its T3-managed thread without requiring a browser or mobile client to open it. If the thread is settled, T3 should unsettle it when processing starts. If the thread is already active, T3 should still restore its missing provider session and process the queue.

Diagnosis

codex queue stores the message in Codex's durable external queue. The Codex queue watcher dispatches messages only for threads that are loaded in an app-server process.

T3 Code had no loaded Codex provider session for this thread. It did not load or resume the session when the external message was queued. Opening the thread caused T3 to restore the provider session, after which Codex consumed the queued message.

This is a provider lifecycle wake gap. It is not message loss, and it does not depend on the T3 thread being settled.

T3 Code needs either automatic detection of queued Codex messages or an authenticated wake operation for external callers. A wake should:

1. Resolve the T3 thread from its Codex thread ID.
2. Load or reconnect the Codex provider session.
3. Resume the Codex thread.
4. Let Codex consume the message that is already in its queue.
5. Show the thread as running while processing occurs.
6. Unsettle the thread if it is settled.
7. Remain safe when called more than once.

The wake operation must not submit the callback text again because that would risk a duplicate turn.

Steps to reproduce

1. Start T3 Serve and create or resume a Codex thread through T3 Code.
2. Leave the thread so that its Codex provider session is no longer loaded.
3. From another process, run codex queue --thread <thread-id> --message <text>.
4. Do not open the thread in a browser or mobile client.
5. Observe that the queued message is not processed.
6. Open the thread in T3 Code.
7. Observe that T3 loads the provider session and the queued message starts processing.

Version

T3 Code 0.0.43-nightly.20260917.1866

Environment

Linux x86_64, T3 Serve, T3 Code mobile client, Codex CLI 0.154.0

Evidence

External work started:       10:46:05 PM CDT (UTC−05:00)
External work completed:     12:42:06 AM CDT (UTC−05:00)
Callback queued:             12:42:22 AM CDT (UTC−05:00)
Callback processed by T3:     6:31:14 AM CDT (UTC−05:00)
Queue-to-processing delay:    5:48:52

Processing started only after the thread was opened in the T3 Code mobile app.

Related issues

#5123 requests an atomic guarded operation that submits a new turn to an idle thread. This report is different: the message already exists in the Codex queue, the T3 thread was not settled, and T3 must restore the provider session so Codex can consume the queued message.

Fix applied or workaround

Opening the thread causes T3 Code to load the provider session and process the queued message. This requires user action and does not support unattended callbacks.

Filed by

Me & Codex 5.6 sol

Start with the T3 Serve handling for externally queued codex queue messages and the T3 Code provider-session loading path. Trace how a Codex thread ID maps to a T3 thread, then how sessions are restored and resumed when a thread opens. Done means queued messages wake unattended threads, settled threads become unsettled, active threads restore missing sessions, processing is visible, repeated wakes are safe, and the callback is not submitted again.