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

Open 💬 2 comments Opened Aug 3, 2026 by Gablas

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

| Opened affected task | Navigation away processed | Stall |
|---|---|---:|
| 08:08:26.605Z | 08:08:58.463Z | 31.858 s |
| 08:10:59.627Z | 08:11:30.892Z | 31.265 s |
| 08:12:02.691Z | 08:12:33.981Z | 31.290 s |

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?

Start a still-running Codex Desktop task that uses the in-app Browser.
Navigate to another task.
Click the Browser-using task in the sidebar.
While the app is stalled, click a different task.
Observe that the entire app remains unresponsive and the second navigation is not processed for about 31 seconds.
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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 25 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#35632
#35637
#35475

Powered by Codex Action

Gablas · 24 days ago

Additional evidence from another reproduction on the same machine and app build narrows this to the Picture-in-Picture snapshot path.

Immediately after Browser Use published its PiP presentation, the app started a ScreenCaptureKit window-image request and did not recover until the fixed 30-second timeout expired:

14:56:46.342  RemoteHostedPIPContent received aspect ratio ... sourceWidth=2560 sourceHeight=1440 displayWidth=400 displayHeight=225
14:56:47.242  ScreenCaptureKit SLSWindowListCreateImageProxying request
14:57:17.244  ScreenCaptureKit SLSWindowListCreateImageProxying unable to complete request due to timeout
14:57:17.316  RemoteHostedPIPContent completed

The same request/timeout pair repeated several times:

| Request | Timeout | Duration |
|---|---|---:|
| 14:56:47.242 | 14:57:17.244 | 30.002 s |
| 14:57:25.860 | 14:57:55.860 | 30.000 s |
| 14:57:57.275 | 14:58:27.277 | 30.002 s |
| 14:58:27.909 | 14:58:57.909 | 30.000 s |
| 15:00:15.857 | 15:00:45.858 | 30.001 s |

During each interval, the entire Desktop UI ignored input and resumed when the timeout returned.

A native capture check outside the app also failed:

/usr/sbin/screencapture -x <temporary-path>
could not create image from display
exit code: 1

This shows that the macOS capture pipeline was unhealthy, but the app-level problem is that the PiP path waits for the full ScreenCaptureKit timeout while blocking the UI. Chronicle was not running during this reproduction, so this is not obviously an active Chronicle saturation loop.

Likely related but not exact duplicates:

#20313 covers the shared replayd / ScreenCaptureKit failure family.
#35756 covers the Browser Use PiP surface becoming unresponsive.

Suggested product boundary: PiP snapshot/capture reconciliation should run away from the main UI path and fail fast or retain the last frame when ScreenCaptureKit is unavailable.