What version of Codex is running?
- Installed CLI:
codex-cli 0.150.1
- Affected persisted thread was created by Codex Desktop / CLI
0.146.1
- A new working thread in the same Desktop/app-server process was created by CLI
0.149.1
- Auth mode: ChatGPT (
codex login status reports Logged in using ChatGPT)
What platform is your computer?
Ubuntu 22.04.5 LTS, Linux 6.8.0, x86_64. Codex Desktop is driving a local/SSH-style app-server session (source = "vscode" in persisted thread metadata).
What issue are you seeing?
An older Desktop thread can be read successfully, but every new prompt in that thread fails with:
unexpected status 401 Unauthorized: {"detail":"Unauthorized"},
url: https://chatgpt.com/backend-api/codex/responses
At the same time, a newly created thread in the same app-server process, with the same ChatGPT account and workspace, sends prompts successfully.
The key persisted metadata difference is:
affected old thread: model_provider=openai_http, cli_version=0.146.1
working new thread: model_provider=openai, cli_version=0.149.1
The legacy provider is still present in config.toml:
[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
supports_websockets = false
startup_timeout_sec = 60
It has no custom base_url or API-key environment variable and historically used ChatGPT authentication. The affected installation contains many persisted threads with this legacy provider name.
Local logs have also reported token_revoked / token_invalidated for the legacy request path, even though the current login status is valid and new openai threads work. This suggests that resume preserves a legacy/custom provider route whose OAuth/token refresh context is no longer compatible with the current built-in ChatGPT provider.
The failure is isolated to turn submission. SQLite integrity checks pass, persisted messages are readable, and the current thread works, so this is not a general network, account-plan, or history-database failure.
What steps can reproduce the bug?
- Configure a provider alias equivalent to the old HTTP-only OpenAI route:
[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
supports_websockets = false
- Sign in with ChatGPT and create a Desktop conversation using
model_provider = "openai_http" on an older Codex version.
- Upgrade Codex/Desktop so newly created ChatGPT threads use the built-in
model_provider = "openai".
- Confirm
codex login status reports a valid ChatGPT login and that a new openai thread works.
- Open the persisted
openai_http thread and submit a follow-up prompt.
- Observe repeated POST failures to
/backend-api/codex/responses with HTTP 401 {"detail":"Unauthorized"}.
What is the expected behavior?
Resuming a persisted thread should remain usable after upgrading Codex.
If a legacy provider alias represents the built-in ChatGPT/OpenAI route, Codex should either:
- migrate or normalize it to the current built-in
openai provider;
- refresh/rebind authentication correctly for the persisted provider; or
- show an actionable provider/auth migration error before submitting the turn.
It should not display the history normally and then fail every follow-up with a generic 401 while new threads work under the same login.
Additional information
The persisted provider is present both in state_5.sqlite:threads.model_provider and the rollout session_meta.payload.model_provider. Manually rewriting both locations may be a workaround, but it is risky for long sessions containing provider-bound encrypted content and should not be required.
Related issues:
Request IDs, account identifiers, thread identifiers, local usernames, and absolute paths have been omitted.
What version of Codex is running?
codex-cli 0.150.10.146.10.149.1codex login statusreportsLogged in using ChatGPT)What platform is your computer?
Ubuntu 22.04.5 LTS, Linux 6.8.0, x86_64. Codex Desktop is driving a local/SSH-style app-server session (
source = "vscode"in persisted thread metadata).What issue are you seeing?
An older Desktop thread can be read successfully, but every new prompt in that thread fails with:
At the same time, a newly created thread in the same app-server process, with the same ChatGPT account and workspace, sends prompts successfully.
The key persisted metadata difference is:
The legacy provider is still present in
config.toml:It has no custom
base_urlor API-key environment variable and historically used ChatGPT authentication. The affected installation contains many persisted threads with this legacy provider name.Local logs have also reported
token_revoked/token_invalidatedfor the legacy request path, even though the current login status is valid and newopenaithreads work. This suggests that resume preserves a legacy/custom provider route whose OAuth/token refresh context is no longer compatible with the current built-in ChatGPT provider.The failure is isolated to turn submission. SQLite integrity checks pass, persisted messages are readable, and the current thread works, so this is not a general network, account-plan, or history-database failure.
What steps can reproduce the bug?
model_provider = "openai_http"on an older Codex version.model_provider = "openai".codex login statusreports a valid ChatGPT login and that a newopenaithread works.openai_httpthread and submit a follow-up prompt./backend-api/codex/responseswith HTTP 401{"detail":"Unauthorized"}.What is the expected behavior?
Resuming a persisted thread should remain usable after upgrading Codex.
If a legacy provider alias represents the built-in ChatGPT/OpenAI route, Codex should either:
openaiprovider;It should not display the history normally and then fail every follow-up with a generic 401 while new threads work under the same login.
Additional information
The persisted provider is present both in
state_5.sqlite:threads.model_providerand the rolloutsession_meta.payload.model_provider. Manually rewriting both locations may be a workaround, but it is risky for long sessions containing provider-bound encrypted content and should not be required.Related issues:
model_providerduring resumeRequest IDs, account identifiers, thread identifiers, local usernames, and absolute paths have been omitted.