[macOS][CLI] Phantom auth error on resume; thread works after prompt

Summary

I use ChatGPT Desktop for some Codex threads and the standalone Codex CLI for others on the same macOS machine and ChatGPT account.

One existing local CLI thread emits the following error during resume/bootstrap:

Your access token could not be refreshed because you have since logged out or signed in to another account. Please sign in again.

However, this is a phantom error: the thread is actually usable. Sending the next prompt to that thread works normally, without another login. Another existing thread resumes without this warning under the same current login and machine state.

Environment

• macOS on Apple Silicon
• Uses both ChatGPT Desktop and the standalone Codex CLI for different threads on the same machine/account
• Standalone CLI: codex-cli 0.148.0
• ChatGPT Desktop bundled runtime: codex-cli 0.148.0-alpha.21
• Authentication: ChatGPT OAuth stored in ~/.codex/auth.json (cli_auth_credentials_store = "file")
• Local resume, not an SSH remote connection
• Several Codex app-server clients/integrations were running concurrently (Desktop, VS Code integration, and other local integrations)

Reproduction

1. Start from a fresh zsh process.
2. Run codex resume <affected-thread-id> for the affected existing local thread.
3. The CLI emits the error above during startup.
4. Send a prompt to the apparently failed resumed thread.
5. The prompt is processed normally; the thread was usable despite the error.

The affected thread's local rollout remains intact and records a terminal event with codex_error_info: "unauthorized" before the usable subsequent interaction.

Diagnostics already attempted

• codex logout, then browser-based codex login, then retry: the phantom error remained, but the thread was usable afterward.
• Resuming from the original repository directory and without model/config overrides: same result.
• Started a fresh zsh process: same result.
• Confirmed the active local auth cache has ChatGPT mode plus non-empty access and refresh tokens.
• Confirmed no CODEX_ACCESS_TOKEN, OPENAI_API_KEY, OPENAI_BASE_URL, or CODEX_HOME override is present in the shell or GUI launch environment. No secrets are included here.

Expected behavior

If a resumed thread is usable, Codex should not show or persist a terminal unauthorized / re-login error. The CLI should either complete resume cleanly or report a non-terminal warning with accurate recovery guidance.

Potentially related issues

These may share an auth-cache / app-server symptom, but this report differs because the affected thread remains usable after the displayed error:

• https://github.com/openai/codex/issues/22419 — exact user-facing error persists until a stale remote connection is restarted.
• https://github.com/openai/codex/issues/19531 — macOS Desktop/connection path still fails after successful login and deleting/recreating local auth.
• https://github.com/openai/codex-plugin-cc/issues/281 — app-server-mediated flows show the exact error after logout/login while direct codex exec with the same auth cache works.

I can provide the affected thread ID, a sanitized rollout excerpt, and process/version details privately if maintainers need them.

Start at the codex resume <affected-thread-id> bootstrap path and inspect how the local ~/.codex/auth.json state and concurrent app-server clients produce the terminal codex_error_info: "unauthorized" event. Reproduce with the listed CLI versions and rollout, then verify that a usable resumed thread completes cleanly or reports only an accurate non-terminal warning.