Repository navigation
[macOS][26.908.31457] cua_repl js tool is available but cua global is undefined after reset #44724
Description
What version of the Codex App are you using?
ChatGPT/Codex Desktop 26.908.31457 (build 8690). The running process is /Applications/ChatGPT.app/Contents/MacOS/ChatGPT.
Bundled components observed:
- Codex CLI:
0.154.0-alpha.6.1 unified-computer-use@openai-bundled:26.908.31457
What subscription do you have?
Signed-in ChatGPT account; the exact subscription tier was not inspected for this reproduction.
What platform is your computer?
macOS 26.6.2 (25G83), Apple Silicon (arm64).
What issue are you seeing?
The cua_repl/js MCP tool is present and accepts JavaScript, but the documented cua global is not defined. Browser control therefore fails before creating or selecting an in-app Browser tab.
Following the tool's first-call instructions exactly:
let tab = await cua.createBrowserTab("iab", "https://example.com", { visible: true });returns immediately with:
cua is not defined
Resetting the JavaScript kernel succeeds, but does not restore the global:
cua_repl/js_reset -> js kernel reset
The required initialization call after reset:
await cua.getState();returns the same error:
cua is not defined
The failure reproduced again with https://example.com, so it occurs before target-site access or authentication.
What steps can reproduce the bug?
- Launch ChatGPT/Codex Desktop on macOS.
- Start a task with the bundled unified computer-use/browser integration enabled.
- Ask the task to open
https://example.comin the visible in-app Browser. - Let it invoke
cua_repl/jswith the documentedcua.createBrowserTab(...)call. - Observe
cua is not defined. - Invoke
cua_repl/js_reset. - Invoke
cua_repl/jswith exactlyawait cua.getState();as required after a reset. - Observe
cua is not definedagain.
What is the expected behavior?
The cua_repl/js runtime should inject the documented cua global. cua.getState() should return the enabled surfaces, and cua.createBrowserTab("iab", ...) should create and return an in-app Browser tab binding.
Additional information
This appears related to the current browser/computer-use initialization and lifecycle reports, but none of them contains this exact symptom: the MCP tool itself is callable while its required global is absent.
Related issues:
- macOS: cua_repl does not respawn after launch.mjs/node_repl exit; createBrowserTab returns Transport closed in ~1ms #44518 —
cua_repldoes not respawn after its host exits; reset does not recover it - [macOS][26.831.21537] cua_repl trusted worker drops NODE_REPL_TRUSTED_SERVICES and crashes before browser attachment #42757 — trusted worker crashes before browser attachment on macOS
- [macOS][26.814.41407] In-app Browser runtime exits during initialization; rollback restores it #39591 — in-app Browser runtime exits during initialization on macOS
- [macOS Desktop] In-app Browser control unavailable because bundled node_repl MCP client never becomes ready #38549 — browser-control MCP client never becomes ready on macOS
No private target URL, page content, credentials, account identifiers, or raw configuration files are included.
Activity
jaglogaiyan commentedon Sep 11, 2026
Additional regression-boundary evidence:
Browser control was working on this machine until the desktop app was updated, then the
cua is not definedfailure began on the new release.Local Codex desktop logs corroborate the release transition:
2026-09-11T02:40:35Z: desktop release26.707.722212026-09-11T03:03:25Z: desktop release26.908.3145726.908.31457(build8690), withunified-computer-use@openai-bundled26.908.31457The exact public-page reproduction in the issue was performed after that transition. This narrows the observed regression boundary to
26.707.72221->26.908.31457on the same Apple Silicon Mac.littlePoBoy commentedon Sep 18, 2026
I’m seeing the same
cuaglobal issue on a newer Codex Desktop version.Environment
26.915.3102926arm64)Reproduction
The
node_replJS tool is available and executes JavaScript normally, but thecuaglobal is not injected.Running:
returns:
And:
fails with:
So the failure occurs before any browser/website interaction.
I noticed this issue is reported against
26.908.31457, while I’m on26.915.31029, but the behavior appears to be the same.Could you confirm whether this is still a known/unfixed regression in the newer builds? If there is a fixed version or a recommended workaround, I’d appreciate any guidance.
Thanks!