Codex receives in-app browser ambient state but browser control tools are not exposed to the agent

Open 💬 1 comment Opened Aug 20, 2026 by Kaveendra
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT Powered by Codex & OWL Version 26.814.41407 Released 18 Aug 2026

What subscription do you have?

Pro

What platform is your computer?

Windows 11, Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary
Codex Desktop shows an in-app browser is open and provides ambient browser context to the agent, but the agent cannot access browser-control tools to inspect, screenshot, navigate, or read the page. Tool discovery only exposed node_repl, not the expected in-app browser control capability, so the agent had to ask the user for screenshots despite the user being logged into the built-in browser.

Environment

  • Product: Codex Desktop
  • Workspace OS: Windows
  • Project path: C:\Projects\AndroidProjects\TimeRyte
  • In-app browser URL: https://cloud.timeryte.com/craneroad
  • Browser plugin appears installed/enabled
  • Browser skill visible later as: browser:control-in-app-browser
  • Current task received ambient state like:

<in-app-browser-context source="ambient-ui-state">

In app browser:

</in-app-browser-context>

What steps can reproduce the bug?

Steps to reproduce

  1. Open Codex Desktop.
  2. Open the built-in/in-app browser side panel.
  3. Navigate to an authenticated web app page.
  4. Ask Codex to inspect the currently open browser page.
  5. The agent searches for browser tools using tool_search.
  6. Tool discovery returns only mcp__node_repl for browser-related work, not direct in-app browser tools.
  7. Agent cannot capture a screenshot or inspect DOM of the actual in-app browser session.

What is the expected behavior?

Expected behavior
When Codex receives in-app browser ambient state and a browser-control skill/plugin is installed, the agent should have callable tools to:

  • navigate the in-app browser,
  • inspect visible page state / DOM,
  • take screenshots,
  • click/type where appropriate,
  • use the existing logged-in browser session.

Additional information

Actual behavior
The agent can see ambient metadata that the in-app browser exists and is on the correct URL, but cannot access any direct browser-control tool. It can only use a separate headless/local Chrome path through Node/Playwright, which does not share the user’s authenticated in-app browser session.
This caused the agent to incorrectly end up asking the user for screenshots even though the authenticated page was already open in the Codex built-in browser.

Impact
This breaks an important Codex workflow: user logs into a web app in the built-in browser so Codex can visually verify UI, debug deployed pages, and inspect authenticated state. Without direct browser access, Codex cannot complete visual QA or authenticated web debugging reliably.

Workaround
The agent launched a separate local/headless Chrome via Playwright, but that browser had no authenticated session. The only practical workaround was asking the user to manually provide screenshots.

Additional notes
This seems like a tool exposure / routing issue rather than an app/browser issue:

  • Ambient in-app browser state was present.
  • Browser-related plugin/skill appeared installed.
  • Tool search still did not expose the expected in-app browser control tools.
  • Node/Playwright tools were available, but they are not a substitute for the in-app browser session.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 8 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #39530
  • #38549

Powered by Codex Action