bug: existing Codex thread can remain unusable on dead hard-affinity owner while fresh/side chat works

[myudak]

Pre-flight checklist

• I searched existing issues and confirmed this is not a duplicate of the already-fixed/older-version behavior.
• I am running a supported codex-lb version.
• I can reproduce the problem with the steps below.

codex-lb version

1.23.0

Deployment method

uvx (codex-lb)

Client used against codex-lb

Codex app (desktop / web)

ChatGPT account plan(s) involved

Plus

Model(s) involved

gpt-5.6-sol

Summary

An existing/long-running Codex thread can become permanently unusable when its upstream owner/account becomes unavailable, even though other healthy accounts are still available in the pool.

The strongest signal is that the exact same Codex client works immediately when I use /side chat or Continue in new chat, while continuing the original thread keeps failing.

This makes the failure look specific to that thread's continuation / hard-affinity state rather than the model, client, endpoint, or global account pool.

This still reproduces on 1.23.0.

Related older report: #1505 describes hard_affinity_saturated when a codex_session owner becomes unavailable. The issue here is that I am still seeing effectively the same user-visible failure on 1.23.0, including after clearing sticky-session mappings.

What happened?

The original thread repeatedly fails with:

No account selected strategy=capacity_weighted sticky=True model=gpt-5.6-sol error=No available accounts
proxy_error_response ... status=503 code="hard_affinity_saturated" message="No available accounts"

and sometimes degrades into:

No account selected strategy=capacity_weighted sticky=True model=gpt-5.6-sol error=No available accounts
Operating in degraded mode: all upstream accounts are unavailable
proxy_error_response ... method=POST path=/backend-api/codex/responses status=404 code="upstream_error" message="Not Found"
INFO: 127.0.0.1:xxxxx - "POST /backend-api/codex/responses HTTP/1.1" 404 Not Found

Remote compaction in that thread also fails:

Error running remote compact task: unexpected status 404 Not Found: Not Found,
url: http://127.0.0.1:2455/backend-api/codex/responses

At the same time, the dashboard showed two other active accounts with substantial weekly capacity remaining (~75% and ~91%). One exhausted/paused account was at 0%.

So the user-visible state is effectively:

old thread -> unavailable owner / continuation anchor -> No available accounts
new chat   -> healthy account selected -> works
side chat  -> healthy account selected -> works

Important observations

1. Fresh threads work.

   • /side chat works.
   • Continue in new chat works.

2. The original thread does not.

   • Retrying it keeps producing No available accounts / hard_affinity_saturated / 404 degraded-mode errors.

3. Healthy accounts exist.

   • Dashboard showed two active Plus accounts with roughly 75% and 91% weekly quota remaining.

4. Deleting sticky sessions did not recover the original thread.

   • I cleared/deleted durable sticky sessions from the dashboard.
   • The original thread still failed afterward.

5. Disabling the dashboard Sticky threads setting did not recover the original thread.

   • This suggests the failure is coming from hard Codex continuation affinity / bridge state rather than the optional soft sticky-routing preference.

6. Lowering sticky thresholds is not a real fix.

   • Lower thresholds may move soft sticky sessions earlier, but they do not repair an already-broken hard continuation owner.

Expected behavior

If a thread's owning account becomes durably unavailable while another compatible healthy account exists, codex-lb should do one of the following automatically:

1. Preferred: safely migrate/replay/re-anchor the thread to another eligible account and continue the same Codex thread; or
2. If migration is impossible because the upstream continuation state is account-bound, return a specific actionable error explaining that this thread cannot be resumed on another account and why.

It should not present this as a generic global pool failure when healthy accounts exist.

In particular, I would expect something like:

continuation owner A unavailable
-> invalidate/rebuild dead bridge/affinity anchor
-> select healthy account B
-> replay sufficient context / create fresh upstream continuation
-> continue same local Codex thread

instead of:

healthy accounts exist
-> No available accounts
-> 503 hard_affinity_saturated / degraded 404

Steps to reproduce

1. Run codex-lb 1.23.0 with multiple Plus accounts.
2. Start and use a Codex thread long enough that it has normal continuation state / compaction history.
3. Let the account that owns that thread become unavailable (quota exhausted, paused, cooldown/backoff, etc.).
4. Confirm at least one other compatible account is still Active and has quota remaining.
5. Continue the original Codex thread.
6. Observe repeated No available accounts, sometimes hard_affinity_saturated, and/or degraded-mode 404s.
7. Delete the durable sticky-session mapping and retry the original thread.
8. Disable Sticky threads and retry the original thread.
9. Observe that it can still fail.
10. Use /side chat or Continue in new chat from the same work/context.
11. Observe that the fresh continuation works immediately.

Relevant logs

No account selected strategy=capacity_weighted sticky=True model=gpt-5.6-sol error=No available accounts
proxy_error_response request_id=95680d60-f145-4c67-9d8f-068d40691952 method=POST path=/backend-api/codex/responses status=503 code="hard_affinity_saturated" message="No available accounts"
INFO:     127.0.0.1:63817 - "POST /backend-api/codex/responses HTTP/1.1" 503 Service Unavailable

No account selected strategy=capacity_weighted sticky=True model=gpt-5.6-sol error=No available accounts
Operating in degraded mode: all upstream accounts are unavailable
proxy_error_response request_id=a50aae6c-d255-4552-b61e-52bc00f6b2e1 method=POST path=/backend-api/codex/responses status=404 code="upstream_error" message="Not Found"
INFO:     127.0.0.1:58169 - "POST /backend-api/codex/responses HTTP/1.1" 404 Not Found

Why this is especially confusing

The dashboard's Sticky threads toggle looks like it controls whether threads remain pinned to accounts. However, turning it off does not necessarily remove hard Codex continuation affinity. From the user's perspective this looks like the setting is being ignored:

Sticky threads OFF
healthy Account B available
old thread still behaves as if pinned to Account A

If hard continuation affinity must remain regardless of that setting, the UI should explicitly distinguish soft sticky routing from hard Codex continuation ownership.

Current workaround

The only reliable workaround I found is to create a fresh continuation:

• /side chat, or
• Continue in new chat

Both work while the original thread remains broken.

That preserves some usability, but it should not be necessary just because one upstream account became unavailable.

Suggested diagnostics / acceptance criteria

It would help if a failed selection logged or surfaced:

• affinity kind (codex_session, bridge owner, turn-state, etc.)
• owning account ID
• why that owner is unavailable
• number of otherwise eligible accounts
• whether cross-account continuation replay/migration was attempted
• why migration was rejected, if rejected

A fix would ideally make the original thread automatically recover to another compatible account, or produce a precise continuation_owner_unavailable-style error instead of a misleading generic No available accounts / degraded 404.

[myudak]

wtf does INFO: 127.0.0.1:58260 - "POST /backend-api/codex/responses HTTP/1.1" 404 Not Found No account selected strategy=capacity_weighted sticky=True model=gpt-5.6-sol error=No available accounts Operating in degraded mode: all upstream accounts are unavailable proxy_error_response request_id=1da5d0e2-3e94-47c1-871b-07b56693c187 method=POST path=/backend-api/codex/responses status=404 code="upstream_error" message="Not Found" meansssssss? i still have a limit on my acc? what the fuck even are the options on these daahsboard meanss,, so many things can be better for this project

[myudak]

how the fuck do i know what error even is this

[myudak]

[myudak]

make the settings page have search function

[myudak]

heres a better idea: make a better documentation for the dashboard shit

[myudak]

its not error when compacting in other threads???????,, is it have something to do with sticky stuff

[myudak]

deleting sticky sessions doesnt do anythingg

do i need to work on new threads???? i cant save the old threads?????????

[myudak]

bro I have 2 healthy accounts, JUST FUCKING USE ANOTHER ONE

[myudak]

why the fuck wouldnt it if not found account error just use another account why is it sticky why even i changed the settings not sticky still fucking stickyy, currently im stuck then what the fuckkkkk,, Codex-LB should automatically migrate/replay the old thread when the owning account dies,, i literally am on the latest version Version:
1.23.0

[myudak]

temp solutions,, /side chat work

[myudak]

continue in new chat works too

[myudak]

continue in new chat works too

NVM ITS STILL FUCKING ERROR IS IT STILL USING OLD CACHE ACCOUNT HOLY FUCKKK