[Desktop/macOS] Opening an active Browser task blocks the app for ~31 seconds

Start by reproducing the task-navigation steps on macOS and reviewing the app-server logs alongside the main-thread jank snapshots. Investigate the interaction between Browser-session restoration and screen-recording reconciliation; done means opening the affected task leaves sidebar navigation and the rest of the Desktop UI responsive without repeated timeout stalls.

What version of the Codex App are you using?

• Codex Desktop: 26.727.51351
• Bundle build: 6119
• Chromium: 150.0.7871.182

What subscription do you have?

Not included; this appears to be a local Desktop UI/runtime issue rather than an account-specific behavior.

What platform is your computer?

• macOS 26.5.1 (build 25F80)
• Apple Silicon / arm64

What issue are you seeing?

Opening one particular still-running task that has used the in-app Browser makes the entire Codex window unresponsive for about 31 seconds.

If I click another task while Codex is stalled, the click is not processed until the stall ends. The affected task is a single active turn with many Browser tool calls and a context-compaction marker.

This reproduced three times in the same session:

Immediately after each stall, the Desktop log records:

[sampler-manager] main_thread_jank_snapshot mainThreadJankCountSinceLastSnapshot=1

During the stalled intervals, the app-server sidecar repeatedly records:

screen recording reconcile failed ... screen capture display enumeration timed out after 5 seconds
terminating child process safely (with TERM)
terminating child process forcefully (with KILL)
child process forcefully terminated

The timing and logs suggest screen-recording reconciliation or Browser-session restoration may be blocking a main/UI-thread path. That is a correlation, not a proven root cause.

What steps can reproduce the bug?

1. Start a still-running Codex Desktop task that uses the in-app Browser.
2. Navigate to another task.
3. Click the Browser-using task in the sidebar.
4. While the app is stalled, click a different task.
5. Observe that the entire app remains unresponsive and the second navigation is not processed for about 31 seconds.
6. Repeat; the same delay occurs again.

What is the expected behavior?

Opening any task should keep sidebar navigation and the rest of the Desktop UI responsive. Browser/screen-recording restoration should run asynchronously, time out once, or fail gracefully without blocking the app.

Additional information

Possibly related, but not exact duplicates:

• #33169 — app freezes when accessing existing threads
• #30624 — Browser plug-in / in-app browser freezes
• #25744 — Computer Use helper accumulation and macOS TCC/WindowServer stalls

Task contents, repository/workspace information, local paths, URLs, credentials, and raw logs are intentionally omitted. A narrower redacted diagnostic extract can be prepared privately if maintainers specify what they need.