macOS IAB: localhost input/click/screenshot work, but Jimeng navigation and subsequent reads time out #47265

What version of the Codex App are you using?

ChatGPT desktop, Codex task experience. Installed app bundle version: 26.915.31945 (read from the app's Info.plist).
Browser control tool: bundled mcp__cua_repl.js, Codex In-app Browser (IAB).
Observation date: 2026-09-22.

What subscription do you have?

Not included in this public report. No account or entitlement diagnosis has been established.

What platform is your computer?

macOS 26.6.2.

What issue are you seeing?

In an existing Codex task, the IAB successfully creates a localhost tab and performs actual text input, button clicks, accessibility-state readback, and a nonblank screenshot. Navigating the same tab to the public Jimeng home URL then stalls the control call. The desktop host logs DOM-ready for the destination, but a later read-only attempt to acquire/read/screenshot that existing tab also times out and resets the JS kernel.

This is a narrowed reproduction, not proof that Jimeng itself is down or that every browser route is unavailable. No video generation, upload, paid operation, or account changes were performed in this diagnostic run.

What steps can reproduce the bug?

These steps describe the observed run; reproduction on other machines has not been verified.

1. Serve a simple page locally on 127.0.0.1:18763 with one text input, a button that copies its value into visible output, and a clear button. For example:

<!doctype html><meta charset="utf-8"><title>IAB control probe</title>
<label for="probe">Probe text</label><input id="probe">
<button id="verify">Verify</button><output id="result">Waiting</output>
<button id="clear">Clear</button>
<script>
let count = 0;
document.querySelector('#verify').onclick = () => {
  document.querySelector('#result').textContent =
    'Verified ' + (++count) + ': ' + document.querySelector('#probe').value;
};
document.querySelector('#clear').onclick = () => {
  document.querySelector('#probe').value = '';
  document.querySelector('#result').textContent = 'Cleared';
};
</script>

2. In the supported CUA runtime, open it with:

var tab = await cua.createBrowserTab(
  "iab", "http://127.0.0.1:18763", {visible:true}
);

3. Using fresh AX indices, run setValue → button click → getAXState; then typeText → click → read; then clear → read. All three returned correct visible state in 374 ms, 269 ms, and 292 ms respectively (combined action/read durations). getScreenshot() returned a nonblank image matching the final cleared state.
4. Run:

await tab.goto("https://jimeng.jianying.com/ai-tool/home/?type=video");
await tab.getAXState();

The outer tool invocation reached its configured 20,000 ms limit and returned:

js execution timed out; kernel reset, rerun your request

Because navigation and AX read were in one invocation, this does not establish which await stalled.
5. Do not reload or navigate again. After the kernel reset, bind the same IAB and use the documented alternative API to acquire the known existing tab, read its URL/title, and screenshot it. That combined read-only invocation hit its configured 15,000 ms limit with the same kernel-reset error. No individual sub-operation result was returned, so the exact blocking sub-operation is unknown.

What is the expected behavior?

A working browser-control connection should remain usable after navigation. If navigation or reading fails, return a bounded, specific failure without leaving the task unable to inspect the already-loaded tab. Ideally, expose a supported recovery operation that preserves the task and website session.

Additional information

• Sanitized host-log observations, UTC: at 11:23:03, the original task's IAB route was registered and mapped to the localhost tab; at 11:24:39.144, the host reported browser sidebar dom-ready for the Jimeng URL.
• A separately approved unauthenticated HTTPS HEAD request to that URL returned HTTP/2 200 at 11:25:53 UTC. This only checks basic connectivity; it does not prove the full web application or browser-control integration works.
• Historical No ChatGPT browser route is available errors occurred in this workflow, but that error did not occur during the successful localhost checks. Please do not treat those checks as evidence of a currently missing route.
• No process killing, app restart, browser-data clearing, security weakening, private uploads, or production actions were used for this reproduction.
• Related symptom: # In-app browser renders pages but agent control times out #46137. This report adds a same-tab localhost success control on a newer macOS/app version. It has not established that the route-lifecycle cause proposed there is the cause here.
• Please investigate the IAB navigation / target binding / AX-read lifecycle and advise a supported fix or recovery path. Raw logs, task IDs, local user paths, account data, photos, audio, and production files are deliberately omitted.