Feature request
Please provide a safe way for Codex browser automation to execute/evaluate JavaScript in the actual page context for local/dev preview workflows, or otherwise expose selected page globals intentionally.
Problem
Codex's in-app browser automation can navigate pages, click, drag, screenshot, and run a read-oriented evaluator. However, the evaluator appears isolated from the page's real JavaScript global scope. This means page-defined globals are not visible even when they are intentionally exposed by a local preview page.
From Codex's point of view, this creates a gap for development previews that deliberately expose test/debug hooks on window.
For example, a Unity WebGL local preview page exposes helpers like:
window.unityInstance
window.b
Those hooks allow automated testing/debugging actions such as setting a level, entering a scene, holding a card for visual QA, or placing a card through the same game bridge used by preview tooling. In another preview environment, an agent can call those hooks directly. In Codex's in-app browser, tab.playwright.evaluate() reports those globals as undefined, because it is not evaluating in the same page world.
Trying to route through a javascript: URL is blocked by browser security policy, which is understandable, but there does not appear to be a supported alternative for trusted local preview pages.
Desired capability
Codex should have a supported, safe mechanism for local/dev preview pages to expose automation hooks to the agent. Possible designs:
- a page-context
evaluate mode gated to localhost / explicitly trusted preview origins
- an allowlisted bridge where a page can register named debug methods for Codex to call
- a way for Codex preview tooling to call specific exposed page globals without broad unrestricted script execution
- a documented app/plugin manifest mechanism for trusted local preview hooks
Why this matters
Many local dev previews intentionally expose debug/test hooks for fast verification. This is common for games, WebGL apps, design tools, dashboards, canvas editors, and complex single-page apps.
Without a supported page-context hook, Codex can still do visual/manual-style testing, but it cannot use the same structured preview bridge that a project already built for deterministic QA. That makes Codex less capable than preview environments that can call app-owned debug hooks directly.
Concrete example
A Unity WebGL game has a preview bridge for QA:
b('SetLevel', '2')
b('EnterLevel')
b('HoldCard', 'Cow,0,5')
b('PlaceCard', 'Cow,0,5')These calls are intentionally exposed by the local WebGL template for development/testing. Codex can see and interact with the rendered canvas, but cannot call the bridge because the evaluator cannot access the page globals.
Impact
A supported page-context or registered-hook mechanism would let Codex perform deterministic local preview QA while still preserving browser safety boundaries.
Feature request
Please provide a safe way for Codex browser automation to execute/evaluate JavaScript in the actual page context for local/dev preview workflows, or otherwise expose selected page globals intentionally.
Problem
Codex's in-app browser automation can navigate pages, click, drag, screenshot, and run a read-oriented evaluator. However, the evaluator appears isolated from the page's real JavaScript global scope. This means page-defined globals are not visible even when they are intentionally exposed by a local preview page.
From Codex's point of view, this creates a gap for development previews that deliberately expose test/debug hooks on
window.For example, a Unity WebGL local preview page exposes helpers like:
Those hooks allow automated testing/debugging actions such as setting a level, entering a scene, holding a card for visual QA, or placing a card through the same game bridge used by preview tooling. In another preview environment, an agent can call those hooks directly. In Codex's in-app browser,
tab.playwright.evaluate()reports those globals asundefined, because it is not evaluating in the same page world.Trying to route through a
javascript:URL is blocked by browser security policy, which is understandable, but there does not appear to be a supported alternative for trusted local preview pages.Desired capability
Codex should have a supported, safe mechanism for local/dev preview pages to expose automation hooks to the agent. Possible designs:
evaluatemode gated to localhost / explicitly trusted preview originsWhy this matters
Many local dev previews intentionally expose debug/test hooks for fast verification. This is common for games, WebGL apps, design tools, dashboards, canvas editors, and complex single-page apps.
Without a supported page-context hook, Codex can still do visual/manual-style testing, but it cannot use the same structured preview bridge that a project already built for deterministic QA. That makes Codex less capable than preview environments that can call app-owned debug hooks directly.
Concrete example
A Unity WebGL game has a preview bridge for QA:
These calls are intentionally exposed by the local WebGL template for development/testing. Codex can see and interact with the rendered canvas, but cannot call the bridge because the evaluator cannot access the page globals.
Impact
A supported page-context or registered-hook mechanism would let Codex perform deterministic local preview QA while still preserving browser safety boundaries.