Codex plan badge stays stale after downgrade, and mobile hides the model-access error

[andybergon]

My ChatGPT subscription temporarily dropped from Pro to Free. T3’s Providers page still showed ChatGPT Pro 20x Subscription, but my selected default model, GPT-6 Astra, no longer worked.

Desktop showed:

The 'gpt-6-astra' model is not supported when using Codex with a ChatGPT account.

The all-project default subsequently showed Terra. I couldn’t tell whether the saved default changed or T3 displayed a fallback.

On Android, the thread list showed Error, but opening the same thread showed only Worked for 3.2s, with no visible error message or explanation.

I’ve since resubscribed and Astra works again. The issue is how T3 handles the temporary loss of model access:

• The account badge should reflect the changed plan.
• If the default model becomes unavailable, T3 should explain that and clearly indicate any fallback.
• The opened mobile thread should show the actionable error and label the turn as failed.

Environment: T3 Code Nightly 0.0.41-nightly.20260908.1400, macOS host, Codex CLI 0.153.4, Android client. Android build not captured.

[juliusmarminge]

Thanks for the write-up — this looks like a real product gap, not a one-off after the Pro lapse.

Not a duplicate of #829 (same Codex string, raw dump only), #3747 (desktop raw-JSON banner), or #10545 (usage-limit rows labeled Failed). Those share error plumbing; none cover a stale plan badge after downgrade plus the opened Android thread hiding the model-access error.

What the code is doing

1. Plan badge — Providers shows Authenticated · ChatGPT Pro 20x Subscription from the last Codex account/read (planType: "pro" → codexPlanLabel in CodexProvider.ts). That snapshot is disk-cached and refreshed about every 5 minutes. A live turn can reject Astra immediately while Settings still shows the last Pro probe. A model-not-supported error does not refresh or invalidate the badge. If Codex itself still reports pro after ChatGPT already dropped the model, T3 will keep the Pro label.

2. Default showing Terra — A stored all-project default is kept if the Codex instance is still valid (resolveDefaultProviderModelSelection). The picker then silently substitutes the preferred catalog default (gpt-5.6-sol, then gpt-5.6-terra) when the saved slug is gone (resolveAppModelSelectionForInstance). Codex does not get the Unavailable chip used for OpenCode/Antigravity. So Terra on the control is usually a display fallback, not proof the saved default changed — which matches the confusion.

3. Android list vs opened thread — The server does persist this: Codex error → runtime.error / session.status = "error" + session.lastError. The list can show Error/Failed. The opened thread has no web-style ThreadErrorBanner (ThreadDetailScreen / ThreadFeed). Settled-turn folds only special-case interrupt (“You stopped…”); a failed turn still becomes Worked for 3.2s, which can hide the only actionable line.

Desktop showing the readable Astra sentence is expected; #9950 is about unwrapping raw JSON on that web banner and does not change mobile.

Suggested fix order

1. Mobile opened thread: surface session.lastError and label the turn failed (not “Worked for”) when the session/turn is in error.
2. Settings: refresh or invalidate the Codex plan label when the live account/catalog or a model-access error disagrees with the cached badge.
3. Defaults/picker: if the saved model is missing from the live list, say so and mark any fallback (do not silently swap to Terra).

Repro on current Nightly 0.0.41-nightly.20260908.1400 + Codex 0.153.4 is enough to treat this as confirmed from code. An Android build number would help store-build correlation but is not required.

Keeping this open as a bug.