[macOS][26.825.51511] In-app Browser can read DOM but click/fill/screenshot time out on a claimed user-opened tab

Disclosure: This issue is being submitted by the user's Codex assistant at the user's explicit request and on their behalf. No account information, cookies, browsing history, page content, screenshots, logs, or conversation transcript are attached.

Environment

• Codex Desktop: 26.825.51511 (build 7377)
• Bundled Browser plugin: 26.825.51511
• macOS: 26.2 (build 25C56)
• Architecture: Apple Silicon (arm64)
• Backend: Codex in-app Browser (iab)
• Affected site in this reproduction: a manually opened, signed-in xiaohongshu.com tab

Summary

The in-app Browser can discover and claim a user-opened tab, read its URL/title, and eventually return a DOM snapshot, but every state-changing interaction and screenshot request hangs until the outer browser-control execution times out and resets the JS kernel.

The website itself remains usable through manual interaction. This appears to be a Browser Use control/response-path failure rather than an account, authentication, or website-availability problem.

Reproduction

1. Open Codex Desktop on macOS.
2. Open the in-app Browser.
3. Manually navigate to https://www.xiaohongshu.com/ and remain signed in.
4. Initialize the bundled Browser runtime and select iab.
5. Run iab.user.openTabs(): the live tab is returned.
6. Claim the returned tab: claiming succeeds.
7. Read tab.url() and tab.title(): both succeed.
8. Run tab.playwright.domSnapshot(): it can return, but only after roughly 40 seconds.
9. Attempt any of the following:
   • tab.playwright.getByRole("textbox").fill("test query")
   • tab.playwright.getByRole("textbox").click()
   • tab.cua.keypress({ keys: ["ESC"] })
   • tab.screenshot()
10. The operation never completes normally. The outer execution eventually times out and the browser-control JS kernel is reset.

Observed errors

For locator.fill(...), the locator resolves to exactly one visible, enabled text input, but the action still reaches the selector deadline:

Error: Playwright selector deadline exceeded
locator.fill failed for selector internal:role=textbox
matchCount: 1
visibleCount: 1
disabled: false
type: text

Other interaction and screenshot attempts end with:

js execution timed out; kernel reset, rerun your request

Control observations

• The same in-app Browser could open and read https://example.com/ before the affected signed-in tab was attached.
• Manual interaction with the affected website works normally.
• URL/title discovery works.
• Passive DOM inspection can eventually work.
• Other tasks using the in-app Browser were stopped before retesting.
• Reinitializing the Browser runtime and reconnecting the iab binding did not restore click/fill/screenshot operations.
• The failure is therefore deeper than basic browser discovery, tab claiming, authentication, or page availability.

Expected behavior

Once a user-opened in-app Browser tab is discovered and claimed:

• click, fill, keypress, and screenshot operations should complete;
• or they should fail promptly with a bounded, actionable error identifying the failing layer;
• a single page operation should not hang until the entire browser-control JS kernel is reset.

Impact

Signed-in web research workflows cannot proceed reliably. The agent may appear to have connected successfully because tab discovery and passive reads work, but it cannot search, open notes, inspect comments, or capture screenshots.

Related issues

• #22797 — In-app browser: URL/title works but DOM inspection times out on real pages
• #23208 — In-app browser: locator.fill fails with virtual clipboard errors

This reproduction is different because DOM inspection can eventually succeed, while click, fill, keyboard, and screenshot operations consistently hang and reset the kernel.

Start with the iab tab-claim and Playwright/CUA action paths described in the report. Reproduce the operations against example.com and the signed-in xiaohongshu.com tab, testing DOM snapshots, fill, click, keypress, and screenshots separately. Compare the related issues #22797 and #23208; done means actions complete or fail promptly without resetting the JS kernel.