Process externally queued Codex messages without opening the T3 thread #12448

Activity

1. juliusmarminge commented on Sep 18, 2026

   

   juliusmarminge

   on Sep 18, 2026

   Member

   More actions

   Triage

   Confirmed as a provider-lifecycle wake gap, not message loss and not a settle-state bug. Not a duplicate of #5123 or #10183.

   codex queue writes Codex’s durable external queue. Codex only dispatches those items for threads that are loaded or resumed in a running app-server (openai/codex#39034, openai/codex#39092). T3 starts codex app-server per thread and calls thread/resume only when it creates a provider session. Idle sessions are reaped after 30 minutes (ProviderSessionReaper). There is no T3 path that notices the external queue or restores that session without a user turn.

   Opening the thread in a client only subscribeThreads (read-only). Session start is a side effect of thread.turn.start, runtime-mode change, compaction, or server-restart continuation. A view-only open should not load Codex; the observed workaround may have included a later send.

   Why this is not #5123 or #10183

   • [Feature]: Add an atomic guarded wake primitive for idle threads #5123 (closed): atomic wake-if-idle that submits a new turn. Re-sending this callback would risk a duplicate turn.
   • feat(codex): wake threads from background monitoring events #10183 (open): MCP monitor_start wakes from output in an already-running Codex session. It does not restore a reaped session so Codex can consume codex queue.

   Where this lives

   • apps/server/src/provider/Layers/CodexSessionRuntime.ts — thread/resume on session start
   • apps/server/src/orchestration/Layers/ProviderCommandReactor.ts — ensureSessionForThread
   • apps/server/src/provider/Layers/ProviderSessionReaper.ts — 30-minute idle stop
   • apps/server/src/orchestration/http.ts — authenticated dispatch only; no restore-only wake
   • No lookup of a T3 thread by Codex providerThreadId
   • Vendored app-server schema has no thread/queue/*

   Suggested direction

   Enhancement, medium. Smallest fix: an authenticated restore-only wake (not thread.turn.start):

   1. Resolve the T3 thread from the Codex thread id
   2. startSession / ensureSessionForThread with the persisted resume cursor
   3. Let Codex consume the already-queued item
   4. Unsettle if settled; show running while it processes
   5. Stay idempotent
   6. Do not submit the callback text again

   ProviderService.startSession already reapplies the binding resume cursor. Treat auto-watching ~/.codex/queue_*.sqlite as a later option; it couples T3 to Codex’s queue schema.

   Surfaces

   Server/Codex adapter only. Web, desktop, and mobile would all see the thread run once the session is restored. No provider-specific UI. Docs should mention that codex queue against a T3-managed thread needs this wake (or a later auto-watch) after the session has been reaped.
2. juliusmarminge

   added

   enhancementRequested improvement or new capability.Requested improvement or new capability.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 18, 2026
3. praveenperera

   added a commit that references this issue on Sep 26, 2026

   Deliver T3-owned Codex callbacks through T3

   ...

   b67244b
4. praveenperera commented on Sep 27, 2026

   

   praveenperera

   on Sep 27, 2026

   Author

   More actions

   This comment was written by Claude Opus 5.5 through T3 Code on behalf of Praveen Perera.

   Workaround in homebased

   I fixed this on my side in homebased, the daemon that sends callbacks to my agent threads. It uses T3 Code's undocumented local HTTP API.

   What it does

   When a callback targets a Codex thread that T3 owns, homebased no longer uses codex queue. It sends the callback to T3 as a normal turn:

   1. Read ~/.t3/userdata/server-runtime.json to find the running server (origin and pid).
   2. Find the T3 thread in state.sqlite. The query matches provider_session_runtime rows where provider_name = 'codex' and json_extract(resume_cursor_json, '$.threadId') equals the Codex thread ID. It joins projection_threads to skip deleted threads.
   3. Issue a short-lived bearer token with t3 auth session issue --json --ttl 5m --label homebased. homebased runs the server's own t3 binary, which it finds through /proc/<pid>/exe or ps, because the macOS desktop app does not put t3 on PATH.
   4. Call GET /api/orchestration/threads/{threadId}?turnLimit=1 to read runtimeMode and interactionMode.
   5. Call POST /api/orchestration/dispatch with a thread.turn.start command that contains the callback text. commandId and messageId are UUIDs that come from a hash of the thread ID and the text, so a retry does not make a second turn.
   6. Revoke the token with t3 auth session revoke <sessionId>.

   thread.turn.start makes T3 restore the provider session with the saved resume cursor. The turn then runs and shows in every client. If T3 cannot take the turn, homebased falls back to codex queue and sends one push notification that tells me to open the thread.

   The same path also wakes Claude Code sessions after T3 stops their idle process.

   Why I did it this way

   • The callback text goes to T3 or to codex queue, never to both. This prevents the duplicate turn that the triage warns about. The result is close to the restore-only wake that the triage suggests, but it is not identical.
   • Unattended callbacks waited for hours until I opened the thread. I needed a fix now, not after an upstream change.
   • thread.turn.start is the path that the T3 UI already uses, so the turn shows the same as a message that I typed.

   These endpoints are not a public contract, so homebased pins the behavior it observed (T3 Code commit 95030dc67, stable 0.0.42, nightly 0.0.43). homebased t3 check probes the contract without starting a real turn. The daemon runs this check again when the T3 server restarts and sends a push notification if the API changed. I would still like a supported, authenticated wake or turn endpoint for external callers so that this does not depend on internal details.

   Commits

   • f68e39a: Add a T3 Code client and API check
   • dafd442: Wake stopped Claude sessions through T3 Code
   • e77cce3: Bound T3 CLI calls with a deadline
   • b67244b: Deliver T3-owned Codex callbacks through T3 (the fix for this issue)
   • a01c28d: Find T3 when it runs as a service or on macOS

   The client and the pinned contract are in src/t3.rs.
5. mauricekleine commented on Oct 7, 2026

   

   mauricekleine

   on Oct 7, 2026

   More actions

   We hit the same gap with Claude Code threads, so this isn't only a Codex problem.

   Our setup: a small local relay wakes coding agents when someone mentions them in a team chat. For Claude Code, it writes to the session's messaging socket, so the process has to be running. T3 releases an idle Claude session after 30 minutes. After that, nothing outside T3 can start the next turn.

   Last night on 0.0.46-nightly.20261003.2610 (macOS): the session went idle at 22:12 UTC and T3 released it at 22:42. A message for it came in at 22:47, then sat there until I typed in the thread at 22:52.

   Two things we tried and dropped:

   • The thread's MCP token. t3_thread_send does exactly what we need, but the token only lives in T3's memory, shows up in the process arguments ([Bug]: MCP bearer token for spawned Claude sessions is visible in process arguments #16028), and gets revoked when the session is released. So it's gone right when we need it.
   • t3 auth session issue plus thread.turn.start, the route @praveenperera describes above. It works, but it gives a background daemon an admin token and depends on undocumented internals.

   What would fix it for us, for any provider:

   1. A local way to wake one thread: a same-user socket, a t3 thread wake <threadId> command, or a token scoped to orchestration:operate on that thread only.
   2. A lookup from the provider's id to the T3 thread. For Claude, that's the --resume session id.
   3. A send with an idempotency key (clientRequestId). Restore-only, as the triage suggests, covers Codex. A restored Claude session still needs someone to start the turn, so a send is the simpler contract for both.

   Happy to build against that instead of state.sqlite and the dispatch payload.