[Regression] Remote CLI and /side can no longer coordinate Windows Desktop threads; updates break task continuity

Summary

A cross-host workflow that previously worked has regressed:

Primary Codex thread on a remote Linux host
  -> creates/opens or messages a normal user-owned thread in Windows Desktop
  -> the Windows thread uses the local browser, Chrome extension, plugins, or Computer Use
  -> the result is coordinated back to the primary thread

There are now three user-visible failures in that workflow:

1. A Codex thread running on the remote Linux CLI/SSH-backed host can no longer create, open, hand off to, or send work to a normal thread in the local Windows Desktop app.
2. A temporary /side chat can no longer reliably interact with the main thread or coordinate the creation/messaging of additional visible Desktop threads.
3. When a Windows Desktop update is installed, the app does not reliably relaunch. It must be opened manually, and active work on either side of the Desktop/remote boundary remains paused instead of recovering and continuing.

These symptoms may have independent underlying causes, but together they break one established orchestration and continuity workflow. This report intentionally groups them by user impact and does not claim a single root cause.

By “Desktop thread,” I mean a normal user-owned task that is visible and navigable in the Desktop sidebar. A host-only CLI session, an internal subagent, or a synthesized thread URI is not an equivalent replacement.

Environment

• Local host: Windows Codex Desktop
• Remote execution host: Linux
• Remote Codex CLI observed: 0.150.1
• Same authenticated account/workspace across the authorized surfaces
• Exact Desktop build is not available from the remote thread; it can be supplied privately if required

Reproduction

A. Remote thread -> local Windows Desktop thread

1. Sign in to Codex Desktop on Windows and enable the authorized local capabilities needed for browser/Computer Use work.
2. Connect/use a remote Linux host and start the primary Codex thread there.
3. From that primary thread, ask Codex to create or message a normal user-owned thread on the Windows Desktop host.
4. Observe that the effectful thread-management path is unavailable or cannot produce a real, navigable Windows Desktop thread.
5. Attempts to substitute a remote CLI session or internal subagent do not provide the local Windows browser/plugin environment.

B. /side coordination

1. Open a main Desktop thread.
2. Start /side.
3. Ask the side chat to inspect/coordinate with the main task, or create/message another visible Desktop task.
4. Observe that the side chat cannot complete the coordination path that previously worked.

C. Update/restart continuity

1. Keep one or more long-running tasks active in Windows Desktop and/or on a connected remote host.
2. Install an available Desktop update.
3. Observe that the Desktop app does not reliably reopen by itself.
4. Open it manually.
5. Observe that previously active work remains paused and does not automatically recover and continue.

Actual behavior

• The remote main task cannot route browser/Computer Use work to the already-authorized Windows Desktop environment.
• /side is reduced to an isolated temporary conversation when the required inter-task capabilities are absent.
• Updating adds an unattended interruption: the app may remain closed until manually launched, and in-progress work stays paused afterward.
• The user must manually recreate coordination, find affected tasks, and resume them one by one.
• Context may still exist, but execution continuity is lost.

Expected behavior

Cross-host coordination

The authorized task-management surface should support an explicit, real handoff:

• remote primary thread -> normal Windows Desktop thread;
• Desktop thread -> remote primary thread;
• create/send/handoff operations should create or target user-owned tasks that are actually visible in Desktop;
• the destination task should use the destination host's browser, plugins, credentials, permissions, and Computer Use configuration;
• capability guidance and the callable tool catalog should agree.

/side

As documented, /side should remain a temporary side chat that does not interrupt the main chat, while still retaining the supported ability to inspect or coordinate the main task and authorized user-owned tasks.

Updates and active work

A Desktop update should have a transactional recovery flow:

1. checkpoint active thread/goal/turn ownership;
2. install the update;
3. relaunch the Desktop app automatically, or show an explicit relaunch/progress state;
4. reconnect to authorized remote hosts;
5. recover each active task exactly once;
6. automatically continue tasks that are safe to resume and do not require approval.

If a task cannot be resumed safely, it should remain in a durable “needs approval” or “resume required” state with a clear reason and one-click recovery. The app should not duplicate a partially completed action or silently mark interrupted work as complete.

Product context

The current documentation describes:

• Remote connections as using the connected host's projects, chats, plugins, browser setup, and Computer Use, including continuing the same work from another device:
  https://learn.chatgpt.com/docs/remote-connections
• /side as a temporary side chat that does not interrupt the main chat:
  https://learn.chatgpt.com/docs/reference/slash-commands
• long-running Goal work as supporting pause/resume:
  https://learn.chatgpt.com/docs/long-running-work
• the Desktop app as normally checking for and installing updates automatically:
  https://learn.chatgpt.com/docs/enterprise/manage-app-updates

The documentation does not appear to state that post-update relaunch and task continuation are currently guaranteed; that portion is a reliability/UX request based on the observed interruption.

Related reports

These appear related but do not individually cover the complete Windows Desktop + remote Linux + /side + update-continuity workflow:

• #40865 — effectful inter-task tools missing on Desktop Remote SSH after the dynamic-tools migration
• #37403 — Desktop cannot resume a Remote Control/CLI thread because an active writer remains
• #41523 / #41539 — Windows first launch after auto-update can remain headless
• #32973 — active Goal recovery after an unclean restart can diverge from persisted lifecycle state

Privacy and diagnostics

Account identifiers, organization/company names, hostnames, IP addresses, local usernames and paths, repository names, thread/turn IDs, browser profile names, signed-in sites, screenshots, and conversation contents are intentionally omitted.

Sanitized version information, timestamps, capability inventories, and relevant logs can be supplied through a private support channel if maintainers identify the exact diagnostics needed.

Start by comparing the reported behavior with #40865, #37403, #41523, #41539, and #32973, then read the remote-connections, slash-commands, long-running-work, and manage-app-updates documentation. Reproduce the three workflows across the Linux CLI, Windows Desktop, and /side chat using sanitized diagnostics. Done requires a decided scope, reliable cross-host coordination, and safe update relaunch and task recovery.