Remote Control task loading blocks on Apps/connector initialization

Summary

On Codex Desktop for macOS, reopening an existing Remote Control thread can remain on Loading task when Apps/Connectors are enabled. The same remote thread resumes in about one second when Apps are disabled.

This looks related to eager codex_apps initialization (#24397). Remote stream resets are also seen in this environment, but I am reporting them as a related symptom rather than claiming the same root cause (#32241).

Environment

• Codex Desktop: 26.707.62119
• Remote app-server: 0.144.2
• macOS Desktop client -> managed Remote Control Linux host
• Apps/Connectors, plugins, and the OpenAI Developer Docs MCP were configured on the remote host

Reproduction

1. Open an existing task on a Remote Control host.
2. Restart the managed remote app-server, then reopen/resume the same task from Codex Desktop.
3. Compare the timings with features.apps = true and features.apps = false in the remote host config.

Observed A/B results

With Apps disabled (plugins enabled; Developer Docs MCP disabled), the same remote task repeatedly completed:

• thread/read: 0.666–0.986 seconds
• thread/resume: 0.842–1.044 seconds

With Apps enabled, before the thread could resume:

• thread/read: 51.226 seconds
• Desktop stayed on Loading task

With only the Developer Docs MCP enabled, a cold resume completed, but the first thread/resume was about 9.896 seconds and later recovery attempts could be substantially slower after connector initialization had been exercised.

The expensive path occurs before the user actually invokes any App tool. It appears to initialize/check connector state and tool schemas as part of thread startup.

Related transport symptom

The Desktop logs also contain repeated Remote Control errors:

remote control app-server stream became unknown
remote control app-server stream sequence gap detected

These errors can occur independently of the Apps experiment, so I do not have evidence that Apps directly causes the stream reset. However, the 51-second Apps startup delay makes the task-loading failure much more visible and likely increases its exposure to transport instability.

Expected behavior

Thread startup/resume should not block on Apps/connector initialization or connector authentication when no App tool is used. Apps should ideally initialize lazily on first tool use, or connector initialization should be bounded and isolated from normal task loading.

Related issues

• #24397
• #32241

I can provide sanitized Desktop and remote app-server timing logs if useful.