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

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:

1. Keep several Codex desktop tasks active on Windows.
2. Switch the desktop app to a different ChatGPT account through browser OAuth.
3. Continue using the app.
4. 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.
5. Observe that the main process, bundled app-server, and some tasks can remain alive and continue writing work.
6. Click Try again or launch the app icon again.
7. 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:

1. stop routing new requests through the old account/session;
2. dispose or rebind the old app-server connection;
3. establish and verify a fresh AppServerManager RPC connection for the selected account;
4. rehydrate renderer request/response mappings;
5. 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.

Trace the account-change, update, and renderer-reload paths around AppServerManager, using the reported RPC errors, orphaned responses, and missing promise mappings as the starting evidence. Done means account transitions and recovery safely rebuild or reconcile the RPC state, prevent stale requests, and make active task ownership visible rather than showing a misleading signed-out state.