[Windows desktop] OAuth account transition can disconnect AppServerManager RPC and return UI to sign-in while tasks keep running

Open 💬 7 comments Opened Aug 20, 2026 by jyongchul

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Observed on Windows desktop package 26.814.5517.0
The same RPC failure was also observed on 26.814.5167.0

What subscription do you have?

ChatGPT paid accounts. The user regularly switches between multiple ChatGPT accounts through the browser OAuth flow.

What platform is your computer?

Microsoft Windows 10 Pro, version 10.0.19045, x64.

What issue are you seeing?

After a successful browser OAuth account transition, the Windows desktop app works for a while and then unexpectedly returns to the sign-in page (or the generic "Oops, an error has occurred" surface). The Electron main process, bundled codex app-server, and active backend tasks remain alive.

The desktop logs repeatedly contain:

AppServerManager RPC is not connected
response_orphaned ... transportKind=stdio
No promise for request ID
App server account changed

Try again reloads the renderer but does not rebuild the main-process-to-app-server RPC connection. Launching the app icon again also does not reliably repair the existing main instance.

This creates a dangerous split-brain state: the UI appears signed out or unusable while background tasks continue to execute and append work. A full app restart can reconnect the RPC, but it can also interrupt active tasks, so it is not a safe recovery while work is in progress.

Sanitized evidence

From the affected Windows host on 2026-08-20 (timestamps are UTC):

03:47:52  App server account changed
03:48:57  App server account changed
03:48:59  AppServerManager RPC is not connected
03:49:06  AppServerManager RPC is not connected
03:50:36  App server account changed
03:51:11  App server account changed

08:04:20  App server account changed
08:05:43  AppServerManager RPC is not connected

09:15:17  App server account changed
09:16-09:18 repeated response_orphaned / No promise for request ID

There were also independent RPC disconnects at 00:38:44 and 01:45:50, before the first account-change event in those app lifetimes. Therefore account switching is a strong trigger/amplifier, but not the sole cause.

Aggregate counts in readable logs for the day:

AppServerManager RPC is not connected: 8
App server account changed: 12
response_orphaned: 205
No promise for request ID: 423
refresh_token_invalidated: 0
auth_token_missing: 0

During the latest sign-in-page failure, a 10-second read-only sample confirmed that 11 separate task records continued growing (about 183 KB total), so the backend was still executing work even though the desktop UI had lost its usable authenticated/RPC state.

No email addresses, account IDs, access or refresh tokens, thread IDs, process IDs, private paths, or raw logs are included.

Steps to reproduce

The failure is intermittent but has repeated many times across two desktop builds:

Keep several Codex desktop tasks active on Windows.
Switch the desktop app to a different ChatGPT account through browser OAuth.
Continue using the app.
Observe one of these outcomes later:

the app unexpectedly returns to the sign-in page;
the renderer shows the generic Oops/Try again screen;
the desktop logs AppServerManager RPC is not connected.

Observe that the main process, bundled app-server, and some tasks can remain alive and continue writing work.
Click Try again or launch the app icon again.
The UI reload/second-instance path does not reliably reconstruct the broken RPC connection.

Account switching makes the failure much easier to trigger, but the logs also contain RPC disconnects without a preceding account-change event.

What is the expected behavior?

An OAuth account transition should atomically:

stop routing new requests through the old account/session;
dispose or rebind the old app-server connection;
establish and verify a fresh AppServerManager RPC connection for the selected account;
rehydrate renderer request/response mappings;
preserve or explicitly pause existing tasks with a visible recovery receipt.

If the RPC is lost, Try again should perform a bounded app-server reconnect/reconciliation, not only reload the renderer.

The UI must not present a signed-out/empty state while backend tasks are still executing invisibly.

Why this is not an exact duplicate

Related issues:

#39199: multi-account browser state invalidates a newly issued refresh token.
#39189: workspace-only settings 401 leads to forced refresh/sign-out.
#24263: renderer reload leaves conversation/turn state out of sync while backend work continues.

This report appears adjacent to all three, but the distinguishing evidence is:

no refresh_token_invalidated or auth_token_missing in the affected logs;
the exact AppServerManager RPC is not connected failure;
repeated clustering around App server account changed;
active backend tasks continuing while the desktop presents sign-in/Oops;
renderer retry/second-instance launch does not rebuild the RPC.

Suggested invariant/fix area

Please make account-change, update, and renderer-reload paths idempotently reinitialize AppServerManager, reject stale stdio request mappings, and reconcile active task ownership before showing the main UI. A safe recovery action should report which tasks were preserved, reattached, paused, or require explicit retry.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 8 days ago

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

#39226

Powered by Codex Action

jyongchul · 7 days ago

Reproduced again on Windows desktop package 26.818.2441.0 (package status healthy). This package replaced 26.814.5517.0 through the normal AppX deployment path on 2026-08-21, so the failure is not confined to the earlier 26.814 build.

Sanitized observations from the new app lifetime:

The Electron main process and bundled codex app-server remained alive.
The current Sentry scope again contained AppServerManager RPC is not connected.
Backend task polling remained reachable, and a bounded 10-second read-only sample showed six local task records still growing while the top-level UI was unusable.
No auth_token_missing or refresh_token_invalidated event was present in the readable diagnostic set.
Repeated renderer reload / second-instance launch did not rebuild the broken main-to-app-server RPC relationship.

This strengthens the lifecycle/state-divergence diagnosis: the renderer can lose its usable app-server RPC connection while the packaged app, app-server, and active task engine remain alive. A full app restart is unsafe until active tasks reach explicit completion, so this failure currently has no non-destructive in-app recovery path.

No account identifiers, tokens, session IDs, process IDs, private paths, or raw logs are included here.

jyongchul · 7 days ago

Additional clarification about the account variable:\n\n- Multiple ChatGPT accounts exist in the user's environment, but the affected desktop session was authenticated once to the intended account through the normal browser OAuth flow.\n- The later return to the sign-in/Oops surface was not caused by the user repeatedly initiating OAuth.\n- In the readable diagnostics for this recurrence, account-change notifications appeared, but efresh_token_invalidated and ^Guth_token_missing remained absent.\n- Independent RPC disconnects have also occurred without a preceding account-change event.\n\nSo multi-account state may increase the likelihood of the defect, but normal possession/use of multiple accounts should not require repeated authentication, and it does not fully explain this recurrence. The strongest observed failure remains the renderer/main-process to app-server RPC lifecycle divergence.

jyongchul · 7 days ago

Follow-up after a user-authorized app-only restart and subsequent normal package update:\n\n- The installed Windows desktop package is now 26.818.3698.0.\n- The current app generation started at 15:02:20 KST and its bundled app-server started at 15:02:22 KST.\n- One sanitized AppServerManager RPC is not connected / esponse_orphaned pair occurred about 0.22 seconds after the app root started and about 1.9 seconds before the app-server became available.\n- From app-server startup through the latest readable log write at 15:42:09 KST, there were no further RPC-disconnect, No promise for request ID, ^Guth_token_missing, efresh_token_invalidated, account-change, Oops, or renderer-crash markers.\n\nThis looks like a startup ordering race in the current sample. The observation window is not yet sufficient to declare the issue fixed, because earlier builds sometimes failed later in the same process lifetime. No account identifiers, tokens, session IDs, process IDs, private paths, or raw logs are included.

jyongchul · 7 days ago

Further recurrence on Windows desktop package 26.818.3698.0:

At approximately 15:58 KST, the owner reported that the desktop UI had become unusable again while background tasks were still running.
The package remained Status=Ok with one current app root and one bundled app-server. The app-server was still parented by the current app generation.
A 12-second process sample showed the related processes consuming additional CPU time, and a separate 10-second session-record sample showed four task records growing by 26,904 bytes in total.
Windows Application Error/Hang/WER and AppModel/AppX warning/error events since this app generation started were zero.
The current-generation desktop logs had no new AppServerManager RPC is not connected, No promise for request ID, authentication-missing, refresh-token-invalidated, account-change, Oops, or renderer-crash marker after the startup-time race already reported above.

This recurrence suggests that the user-visible desktop can become unusable while the app-server and active task generation remain healthy, even without a new RPC/auth/crash marker in the readable logs. We intentionally did not restart or terminate the app because multiple task records were actively growing. A supported renderer/UI recovery path that preserves and reattaches to the live app-server generation is still needed.

No account identifiers, tokens, private paths, or raw logs are included.

jyongchul · 4 days ago

Further recurrence on Windows desktop package 26.818.5229.0 on 2026-08-24:

The owner again reported that the desktop UI was unusable while the package and bundled app-server remained alive.
The affected generation had one app root and one directly parented bundled app-server in the same Windows session; package status was Ok and all packaged processes were reported as responding by Windows.
Current-generation readable diagnostics contained response_orphaned 28 times and No promise for request ID 54 times. Mirrored logs may duplicate counts, but recurrence of both markers is unambiguous.
There were zero new AppServerManager RPC is not connected, Oops, missing-token, invalidated-refresh-token, or account-change markers, and zero Windows Application Hang/Error events.

Before recovery, 15 current task records were sampled for 65.4 seconds and then rechecked immediately for 8.4 seconds; none grew and no new task record appeared. A single controlled app-only restart was therefore performed. The exact old package generation and bundled app-server exited, and the app was launched once in the existing logged-on Windows session. No OS reboot, authentication reset, session/config deletion, or broad process termination occurred.

The new app generation started at 16:13:00 KST and its bundled app-server at 16:13:02 KST. Package status remained Ok, the package paths and direct parent relation were correct, and the generation stayed stable through the initial checks. However, no packaged log file was observed updating after the new generation started, so complete recovery cannot yet be claimed.

This confirms another 26.818.5229.0 recurrence where renderer/main request bookkeeping breaks without an accompanying authentication failure or Windows hang event. A supported UI/RPC reattach path that preserves a live task/app-server generation is still needed.

No private identifiers, tokens, private paths, or raw logs are included.