In-app browser Page.captureScreenshot times out while macOS session is locked

What version of the Codex App are you using?

ChatGPT/Codex desktop app 26.707.72221 (build 5307)

Codex CLI installed on the host: codex-cli 0.144.1

What platform is your computer?

• macOS 26.5.2 (build 25F84)
• Apple Silicon / arm64
• MacBook Pro
• Connected to power
• Lid open
• macOS user session locked
• Task hosted by the native ChatGPT/Codex macOS app on this Mac, reached through Remote Control (not an SSH-backed Codex project)

What issue are you seeing?

The Codex in-app browser remains discoverable and controllable while the macOS user session is locked, but viewport screenshot capture reproducibly times out.

This is isolated specifically to screenshot capture:

• Browser discovery succeeds.
• Fresh tab creation succeeds.
• Navigation succeeds.
• Page URL and title reads succeed.
• Screenshot capture fails with a CDP timeout.
• Retrying after the timeout can close the affected tab.

Exact errors reproduced on two independent fresh tabs:

Timed out running CDP command "Page.captureScreenshot" for tab 1
Timed out running CDP command "Page.captureScreenshot" for tab 2

A retry after the first timeout returned:

target closed while handling command

The same in-app browser can capture screenshots successfully when the macOS session is unlocked.

What steps can reproduce the bug?

1. Open ChatGPT/Codex Desktop on a MacBook Pro.
2. Open a Codex task hosted by the native macOS app.
3. Open the built-in in-app browser and verify that screenshot capture works while unlocked.
4. Leave the Mac connected to power with the lid open.
5. Lock the macOS user session.
6. From a connected device, start a fresh task on that Mac.
7. Discover the in-app browser.
8. Create a fresh tab.
9. Navigate the tab to https://example.com/.
10. Read the page title and URL.
11. Capture a viewport screenshot.

Observed before screenshot:

title: Example Domain
url: https://example.com/

Observed during screenshot:

Timed out running CDP command "Page.captureScreenshot"

The result was reproduced in a separate new task to rule out stale per-thread browser configuration.

What is the expected behavior?

If the in-app browser remains available while macOS is locked and can create tabs, navigate, and inspect page state, screenshot capture should also work.

If screenshots are intentionally unsupported while the session is locked, the browser should return a clear, immediate, typed error explaining that limitation rather than waiting for the CDP timeout. The failed capture should not close or destabilize the tab.

What is the actual behavior?

While locked:

| Operation | Result |
|---|---|
| Browser discovery | Succeeds |
| Fresh tab creation | Succeeds |
| Navigation to https://example.com/ | Succeeds |
| Read title and URL | Succeeds |
| Viewport screenshot | Times out |
| Retry after timeout | Can return target closed while handling command |

While unlocked, screenshot capture succeeds.

Why this appears distinct from related issues

• #30605 reports the same Page.captureScreenshot timeout when the Codex app is minimized or hidden. This report provides a deterministic lock-screen trigger even when the MacBook lid remains open and the task is hosted remotely.
• #26743 and #26415 concern locked Computer Use failing to access desktop apps or hanging. This report uses the Codex in-app browser, where tab control and page inspection continue to work and only bitmap capture fails.
• #21560 discusses intermittent recoverability of IAB CDP screenshot timeouts. This report provides a deterministic state-dependent reproduction: unlocked succeeds, locked fails.

These may share an underlying compositor/visibility or CDP timeout path, but the locked-session reproduction and surviving page-control path are not covered by those reports.

Impact

This prevents using an always-on Mac as a remote Codex web-development host for unattended visual verification. Codex can run the development server and inspect the page while the Mac is locked, but cannot return screenshots unless the graphical user session remains unlocked.

No system settings were changed and nothing was installed during the reproduction.