Title: Remote SSH projects fail with token refresh errors after successful authentication (Windows Desktop 26.608.12217)

Open 💬 3 comments Opened Jun 10, 2026 by lozknowles

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.608.12217

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11

What issue are you seeing?

Title: Remote SSH projects fail with token refresh errors after successful authentication (Windows Desktop 26.608.12217)

Environment:

  • Codex Desktop 26.608.12217
  • Windows 11
  • ChatGPT Plus account
  • Remote Linux host: Ubuntu 24.04.4 LTS
  • SSH connectivity verified independently

Problem:
Local projects work correctly, but any remote SSH-backed project fails immediately when a prompt is submitted.

Observed errors:

  • "Failed to refresh token: 400 Bad Request: Your session has ended. Please log in again."
  • "Your access token could not be refreshed because you have since logged out or signed in to another account. Please sign in again."

What was tested:

  • Created a brand-new empty repository on the remote host.
  • Existing repositories and new repositories both fail.
  • SSH access from Windows works normally.
  • Codex Web works normally.
  • Local Codex projects work normally.
  • Logging out and back in does not resolve the issue.
  • Resetting local Codex state and authentication files does not resolve the issue.

Additional observation:
The remote connection authentication flow appears to complete successfully, but subsequent prompts still fail with token refresh errors.

Expected behaviour:
After successful authentication and SSH connection, prompts should execute against the remote repository.

Actual behaviour:
Every prompt fails before repository access occurs.

What steps can reproduce the bug?

What was tested:

  • Created a brand-new empty repository on the remote host.
  • Existing repositories and new repositories both fail.
  • SSH access from Windows works normally.
  • Codex Web works normally.
  • Local Codex projects work normally.
  • Logging out and back in does not resolve the issue.
  • Resetting local Codex state and authentication files does not resolve the issue.

Additional observation:
The remote connection authentication flow appears to complete successfully, but subsequent prompts still fail with token refresh errors.

Expected behaviour:
After successful authentication and SSH connection, prompts should execute against the remote repository.

Actual behaviour:
Every prompt fails before repository access occurs.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

3 Comments

zywang0108 · 2 months ago

I reproduced a very similar Windows Desktop -> remote Linux SSH failure and the fix was on the remote host, not in the Windows app state.

In my case:

  • Windows Codex Desktop showed the same token refresh error for remote SSH projects.
  • Logging out/in locally and clearing Windows-side Codex state did not fix it.
  • The remote host had stale Codex app-server / proxy processes still running, including:
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://

The recovery procedure that fixed it was:

# 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 reconnect/reopen the remote project from Codex Desktop.

Why I think this is relevant: direct remote CLI auth was fine after login, but Desktop remote traffic continued to go through an already-running remote app-server / desktop SSH bridge that appeared to hold stale auth state. Killing those remote processes forced Desktop to start a fresh remote app-server after the new ~/.codex/auth.json existed, and the error disappeared.

This also explains why resetting Windows state alone may not help for SSH-backed projects: the stale state can live inside the remote app-server process.

inlucesum · 1 month ago

I can confirm this issue is still reproducible on the latest Desktop release.

My environment:

  • ChatGPT Desktop 26.707.62119 (released 2026-07-13)
  • Windows 11 Pro (Microsoft Windows NT 10.0.26220.0 x64)
  • Remote Ubuntu 24.04 over SSH via Tailscale
  • Codex CLI 0.144.1

My observations are almost identical to this issue:

  • Desktop Chat works.
  • Desktop Local Projects work.
  • SSH remains connected.
  • Every Desktop Remote Project 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."

Additional information that may help:

The problem started immediately after enrolling in Advanced Account Security from ChatGPT.

I later unenrolled, but the problem persisted.

I have already tried:

  • signing out/in multiple times
  • completely exiting the Desktop app
  • reinstalling the Desktop app
  • creating new Remote Projects

None helped.

However, Codex CLI on the same remote Ubuntu host works perfectly after a fresh browser authentication.

This suggests the issue is isolated to the Desktop Remote Project authentication path rather than SSH connectivity or the OpenAI account itself.

inlucesum · 1 month ago

Update:

The issue has now resolved itself without any additional changes on my side.

Before posting my previous comment, I spent about an hour troubleshooting. During that time I had already:

  • Signed out and back into the Desktop app multiple times.
  • Completely exited the Desktop app.
  • Reinstalled the Desktop app.
  • Verified that Desktop Chat and Local Projects worked.
  • Verified that Codex CLI worked against the same remote host.

None of those actions immediately resolved the issue.

However, after some time, all Desktop Remote Projects suddenly started working again.

Current status:

  • Desktop Chat: ✅
  • Desktop Local Projects: ✅
  • Desktop Remote Projects: ✅
  • Codex CLI: ✅

The triggering event still appears to have been enrolling in Advanced Account Security, but I cannot confirm whether the eventual recovery was due to delayed server-side token propagation, session cleanup, or a backend fix.

Hopefully this timeline helps identify the root cause.