After install, the new issue is coming ... the task stopped automatically without any notification or any prompts.

[zs819]

I hate to bring this up, but I finally got it working after resolving the installation issues. It boasts abundant functions and extensive configuration options. I set up Omniroute with an identical configuration based on the 9router template. However, when I use this exact same template in Codex, the connection keeps dropping constantly with zero continuity, and the task stopped automatically without any notification or any prompts, the same template in 9, the task can run over 10 hrs. I have no clue what went wrong, so I’ve had to roll back to 9router for now. I can't proceed with the task, so I have no choice but to keep using 9 for now. I'll figure out what the root cause is when I get the chance. I'm wondering if anyone has any good suggestions or has run into the same issue. Omniroute has many features that 9 lacks, which really appeal to me — I'd love to switch to it!

[diegosouzapw]

Hey @zs819! Glad you got past the install -- and thanks for staying constructive about it. This one is a real difference in defaults, not something you configured wrong. Two knobs are almost certainly biting you, and a 9router template will not carry either of them over.

1. Codex session affinity is OFF by default (this is the "zero continuity" part).

codexSessionAffinityTtlMs defaults to 0 (src/lib/db/settings.ts:135) = disabled. With it off, every turn of your Codex conversation is routed independently by the combo strategy and can land on a different account, which breaks upstream session/prompt-cache continuity mid-task. It is opt-in by design (it trades load-balancing for continuity), but for a long single Codex task you want it ON.

Enable it: Dashboard → Settings → Routing → "Codex session affinity" → Affinity TTL. Set it comfortably above your task length (max is 86400s = 24h). It will not pin you to an exhausted account -- quota/cooldown filtering runs before affinity selection.

2. The 10-minute idle timeout (this is likely the "stopped without any notification" part).

STREAM_IDLE_TIMEOUT_MS defaults to 600000 (10 min) (src/shared/utils/runtimeTimeouts.ts:10). A watchdog aborts the stream if no upstream chunk arrives for 10 minutes (open-sse/utils/stream.ts:1114-1150). Our synthetic heartbeat does not reset that clock -- only a real upstream chunk does. So a long Codex reasoning turn that goes quiet past 10 minutes gets force-closed, and the CLI just sees the connection die with no message.

Raise or disable it via env var (0 disables):

STREAM_IDLE_TIMEOUT_MS=0

(FETCH_TIMEOUT_MS / FETCH_BODY_TIMEOUT_MS default to 600000 too and accept the same treatment -- see docs/guides/SETUP_GUIDE.md.)

Suggested config for a 10h task: affinity TTL = 86400s, STREAM_IDLE_TIMEOUT_MS=0, then retry the task.

To confirm which one hit you, grep your server log around the moment it died:

Idle timeout: no data from codex

If that line is there, it was #2. If instead you see the task wandering between accounts, it was #1. Either way, paste what you find and I will trace it further.

This is on us: neither knob is mentioned in docs/guides/CODEX-CLI-CONFIGURATION.md, which is why a 9router-shaped config silently underperforms here. Opened #7287 to document the long-running-Codex setup and to reconsider both defaults. Thanks for the honest comparison -- "it runs 10h there and dies here" is exactly the kind of signal that finds real gaps.