Codex Cli/App "Connections" Issues (Unable to send message to remote project getting access token refresh error)

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #18769

Powered by Codex Action

I hit what looks like the same failure on codex-cli 0.128.0 on Darwin 24.3.0 arm64 arm.

User-facing error:

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

With auth tracing enabled, the key log line was:

codex_login::auth::manager: Skipping auth reload because no account id is available.

I dug through codex-rs/login/src/auth/manager.rs and found two related issues:

1. The unauthorized recovery reload path is guarded only by account_id. If cached ChatGPT auth has no account_id, Codex skips reloading auth from storage entirely, even when the on-disk auth is valid or has been refreshed by another Codex process. That can strand the process on stale cached auth and produce the misleading account/logout error.

1. The UnauthorizedRecoveryStep::RefreshToken path calls refresh_token_from_authority() directly. That means after the first recovery reload step, there is still a race where another Codex process can refresh storage before this process tries to refresh using stale cached auth.

I tested a local patch that:

• uses a broader reload identity: account_id, then chatgpt_user_id, then email
• allows guarded reload when no identity claim is available instead of skipping immediately
• changes unauthorized recovery’s refresh step to call refresh_token() so it performs the guarded reload again before hitting the token endpoint
• rejects malformed ChatGPT auth JSON that has no tokens, because codex login status can otherwise say “Logged in using ChatGPT” even though the auth file is unusable

Regression coverage added:

• token-only/malformed ChatGPT auth is rejected
• unauthorized recovery still refreshes when account_id is missing
• unauthorized recovery reloads changed disk auth before the refresh step instead of calling /oauth/token with stale cached credentials

Local verification:

• cargo fmt --check -p codex-login
• cargo test -p codex-login
• full patched CLI build
• codex exec --sandbox danger-full-access --json - smoke test returned OK

Because external PRs are invitation-only per docs/contributing.md, I’m not opening an unsolicited PR, but I can submit the patch if maintainers want it.

I hit what appears to be the same failure when using Codex Desktop on Windows against remote Linux hosts over SSH.

Symptom:

• codex login --device-auth on the remote host succeeds.
• codex exec ... on the remote host works after login.
• Codex Desktop remote project still fails with:

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

What fixed it for me was clearing the stale remote app-server / desktop SSH bridge processes, then logging in again on the remote host before reconnecting from Codex Desktop:

# on the remote SSH host
pkill -u "$USER" -x codex
rm -f "${CODEX_HOME:-$HOME/.codex}/app-server-control/desktop-ssh-websocket-v0.sock"

codex logout
codex login --device-auth
codex login status

Then close/reopen or reconnect the remote project in Codex Desktop.

In my case the old remote processes included commands like:

codex app-server --listen unix://.../desktop-ssh-websocket-v0.sock
codex app-server proxy --sock .../desktop-ssh-websocket-v0.sock
codex app-server --remote-control --listen unix://

Those processes seemed to keep using stale auth state even after a fresh codex login. After killing them and reauthenticating on the remote, Codex Desktop started a fresh remote app-server and the error disappeared.

This also matches the pattern described in openai/codex-plugin-cc#281 where direct codex exec works but app-server-mediated flows keep failing with the stale auth error.