Codex Desktop: SSH remote project with many subagent edges triggers collab_hydration loop and React #185

What version of the Codex App are you using?

Reproduced with both installed Windows packages:

• Stable Microsoft Store package: 26.707.3748.0
• Public beta Microsoft Store package: 26.707.3351.0
• Remote Codex CLI: codex-cli 0.144.1

The package versions above were read from the installed package paths. The same renderer failure was recorded independently by both the stable and beta app logs.

What subscription do you have?

ChatGPT subscription with Codex access. The exact plan is intentionally omitted because it does not appear relevant to this renderer/session-state failure.

What platform is your computer?

• Client: Windows 11, x64
• Remote target: Ubuntu under WSL, accessed through a Codex Desktop SSH connection
• Transport: Windows OpenSSH with a ProxyCommand that reaches the WSL SSH server through the remote Windows host

All hostnames, usernames, domains, IP addresses, device identifiers, hardware details, locale/timezone data, and exact filesystem paths are redacted.

What issue are you seeing?

Opening an existing project under an SSH remote connection repeatedly replaces the Codex Desktop window with the app-wide error fallback. The desktop log shows:

Minified React error #185
name=AppRoutes
component=local-conversation-thread

The SSH transport and remote app-server are healthy:

• The SSH command succeeds non-interactively.
• The project directory exists and is readable.
• The remote locale is UTF-8.
• Remote thread/list responses complete with errorCode=null.
• There is no app-server connection error before the renderer failure.

The affected persisted parent thread has a large multi-agent history:

• Parent rollout size: approximately 24.8 MB
• Persisted child spawn edges: 41
• All 41 edges have status=open
• Every child edge has a matching thread row and rollout
• No duplicate edges, missing child rows, self-edges, or reverse cycles were found
• All inspected JSONL files are valid UTF-8 and their session metadata parses successfully

The open edge status is reported as persisted state only; it does not necessarily mean that 41 child processes are still running.

On the first observed failure, the app performed this sequence:

1. thread/fork was sent for the existing persisted remote parent.
2. The fork response completed successfully with errorCode=null after about 5.8 seconds.
3. thread/inject_items completed successfully for the returned destination thread ID.
4. The returned destination ID was not present afterward in the remote threads table, thread_spawn_edges, session index, or rollout files.
5. The renderer began repeatedly issuing remote thread/list requests with source=collab_hydration.
6. View activity repeatedly toggled between active and inactive while browser-sidebar owner synchronization repeated.
7. Pending hydration requests grew into the twenties before React error #185 reached the AppRoutes error boundary.

Sanitized relative-time excerpt:

T+0.000  thread/fork dispatched
         originHostId=remote-ssh-discovered:<remote>

T+5.832  thread/fork response_routed
         errorCode=null

T+5.864  thread/inject_items completed
         conversationId=<new-destination-thread>
         errorCode=null

T+5.925  thread/list enqueued
         source=collab_hydration

T+7.xxx  repeated thread/list enqueues
         source=collab_hydration
         pendingCountAfter=<increasing>

T+8.0xx  thread_stream_view_activity_changed
         active=true / active=false

T+8.097  error boundary
         errorMessage="Minified React error #185"
         name=AppRoutes

The beta log recorded the same error boundary seven times across repeated attempts. The stable app log recorded the same React #185 failure pattern as well.

This does not appear to be repository content, SSH authentication, filesystem permissions, invalid UTF-8, or a remote CLI version mismatch. It appears to be a renderer/session-lifecycle loop involving remote collaboration hydration, many persisted subagent edges, and a fork destination that remains loaded or usable briefly but is not materialized in persistent thread storage.

What steps can reproduce the bug?

This is repeatedly reproducible with the affected remote project, although I do not yet have a clean synthetic repository reproduction:

1. Configure a Codex Desktop SSH connection to an Ubuntu WSL environment.
2. Add a remote project containing an existing persisted parent thread with many spawned subagent children.
3. Open the remote project and navigate to or fork the affected parent thread.
4. Observe repeated collab_hydration thread/list requests.
5. The main window enters the full-screen error fallback with React #185.

Restarting the remote app-server and trying both stable and beta desktop packages did not remove the failure.

What is the expected behavior?

• An SSH remote project and its existing parent thread should render normally regardless of the number of persisted child threads.
• Collaboration hydration should be bounded and deduplicated.
• A successful thread/fork destination should either be materialized in persistent storage or explicitly treated as ephemeral without poisoning the renderer state.
• Missing or ephemeral conversation state should be handled without a view-activity/update loop.
• React #185 should not reach the app-wide error boundary.
• The fallback should provide an actionable diagnostic rather than suggesting an update when both installed channels reproduce the problem.

Related issues

This appears related to, but has a distinct remote-SSH and hydration-request signature from:

• #31090: React #185 after subagent/session-state problems in a local thread
• #32151: React #185 from a side-dialog/browser-sidebar rebind loop
• #22001: a live or usable ephemeral thread that is absent from persisted thread storage

The distinctive evidence here is the combination of:

• an SSH remote project,
• a persisted parent with 41 valid child spawn edges,
• a successful thread/fork followed by thread/inject_items,
• no persisted row or rollout for the returned destination,
• a burst of remote thread/list calls from collab_hydration,
• and an immediate React #185 renderer loop.