In-app browser automation can control hidden session while visible panel shows Nothing here yet

Summary

During a Codex desktop session, browser automation appeared to successfully open and control the in-app browser at http://localhost:8765/, but the user-visible in-app browser panel still showed a blank state: Nothing here yet.

This created a serious mismatch: Codex reported that it could see and manipulate the app, while the user saw no app at all. The root cause appeared to be that the in-app browser session existed and was controllable through automation, but its visibility state was false. The browser only became visible to the user after explicitly calling the browser visibility capability with visibility.set(true).

This failure mode can make Codex appear to hallucinate browser state, because the model receives successful automation results while the human-visible browser panel remains empty.

Environment

App: Codex Desktop
OS: Windows
Browser target: Codex In-app Browser
Browser plugin path observed: C:\Users\Aniruddha Debnath\.codex\plugins\cache\openai-bundled\chrome\0.1.7
Browser client used successfully: ...\chrome\0.1.7\scripts\browser-client.mjs
Local app URL used for reproduction: http://localhost:8765/
User-visible in-app browser initially showed: Nothing here yet

Reproduction Scenario

User has the Codex in-app browser panel open.
User-visible panel shows Nothing here yet.
Codex uses the browser client to get the in-app browser and open a tab:

const { setupAtlasRuntime } = await import(
  'C:/Users/.../.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/browser-client.mjs'
);
await setupAtlasRuntime({ globals: globalThis });

const browser = await agent.browsers.get('iab');
const tab = await browser.tabs.new();
await tab.goto('http://localhost:8765/');

Automation succeeds and can read page title/body text.
Codex reports seeing the app.
User screenshot still shows the visible in-app browser panel is blank with Nothing here yet.

Expected Behavior

If Codex opens a page in the in-app browser, the visible in-app browser panel should show that page, or Codex should be told clearly that it opened a hidden/background browser session.

Ideally:

browser.tabs.new() in the in-app browser should surface the tab to the visible panel, or
the automation API should warn that the browser is currently hidden, or
the runtime should automatically set visibility to true when the user explicitly asks Codex to open/view/manipulate the in-app browser.

Actual Behavior

Codex could control and read a page in the in-app browser session while the user-visible panel remained blank.

Observed automation result:

{
  "ok": true,
  "title": "NovelTranslations Archive Browser",
  "url": "http://localhost:8765/",
  "bodyPreview": "NovelTranslations Archive Browser\n\n7340 comments in 150 threads..."
}

But the user-visible browser panel showed:

Nothing here yet

Root Cause Found During Session

The in-app browser visibility state was false.

This call exposed the issue:

const visibility = await browser.capabilities.get('visibility');
await visibility.get();

Result:

false

After running:

await visibility.set(true);

the browser became visible to the user, and the page appeared correctly.

Related API Ergonomics Bug

The visibility API schema was unclear.

This call failed:

await visibility.set({ visible: true });

Error:

Expected boolean, received object
path: ["visible"]

The working call was:

await visibility.set(true);

The capability description says it controls visibility, but the expected argument shape was not obvious. The error path mentioning visible made it look like { visible: true } should be valid, while the method actually expected a bare boolean.

Documentation / Discoverability Issue

The capability metadata referenced docs such as:

docs/capabilities/browser/visibility.md
references/capabilities/browser/visibility.md

Those docs were not found in the local plugin folder when searched, making it difficult to discover the correct API shape.

Additional Browser-Related Failures Observed

Intermittent inability to attach to the in-app browser

Earlier in the session, attempts to access the browser panel failed even though the user had the in-app browser open and the context reported a current URL. Codex could not reliably attach to that visible browser state, which created confusion because the user could see the app while Codex could not interact with it.

Stale browser client path confusion

An older attempted browser-client path failed:

...openai-bundled/browser-use/0.1.0-alpha2/scripts/browser-client.mjs

The working path was:

...openai-bundled/chrome/0.1.7/scripts/browser-client.mjs

If internal tooling, examples, or compacted context retain stale browser-client paths, Codex may fail to attach even though the newer Chrome plugin is installed.

Automation state and visible user state can diverge

This was the most serious problem. Codex had a valid controllable browser object and a loaded page, but the human-visible in-app browser panel was still empty. There needs to be stronger synchronization between the selected visible in-app browser tab, hidden/background automation tabs, browser.tabs.selected(), browser.tabs.new(), and browser visibility state.

Why This Matters

This failure mode makes Codex appear to hallucinate. From the model side, automation returns real title/body/URL data. From the user side, nothing is visible. The user reasonably concludes Codex is lying or stuck in an agentic loop.

For browser-based debugging and demos, visibility mismatch is a high-impact UX bug.

Suggested Fixes

When using agent.browsers.get('iab'), expose whether the browser is visible in the default returned object or warning output.
If the user explicitly asks to open/view the in-app browser, automatically set visibility to true.
Make browser.tabs.new() in the in-app browser visible by default, or document clearly that it may create a hidden tab/session.
Improve the visibility API docs and make them available at the path referenced by capability metadata.
Accept both API shapes if possible:

visibility.set(true)
visibility.set({ visible: true })

Provide clearer error messages when Codex controls a hidden browser session.
Ensure compacted context or internal examples do not point to stale browser-client paths.
Add an explicit “claim visible in-app browser panel” operation, similar to claiming Chrome tabs.

Minimal Working Recovery Code

const { setupAtlasRuntime } = await import(
  'C:/Users/Aniruddha Debnath/.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/browser-client.mjs'
);

await setupAtlasRuntime({ globals: globalThis });

const browser = await agent.browsers.get('iab');

const visibility = await browser.capabilities.get('visibility');
await visibility.set(true);

const tab = await browser.tabs.selected().catch(() => browser.tabs.new());
await tab.goto('http://localhost:8765/');

User-Facing Symptom

The user saw:

Nothing here yet

while Codex reported:

NovelTranslations Archive Browser
7340 comments in 150 threads

That mismatch is the core bug.

Additional related failure mode: visible in-app browser pane existed, but automation bridge could not attach

I want to add a second, related browser failure mode from the same session. This is distinct from the hidden-session issue in the main report.

In the main issue above, the automation bridge could control a browser session, but that session was hidden from the user until visibility.set(true) was called.

In this earlier failure mode, the user-visible in-app browser pane was open and the conversation context reported an active URL, but Codex could not attach to it at all. The bridge returned:

No active Codex browser pane available

So this was not just a hidden-tab problem. It looked like a bridge registration/attachment problem.

Summary

Codex was unable to control or inspect the visible in-app browser pane even though the browser pane was open in the Codex UI and the conversation context explicitly reported an active in-app browser URL.

The local app was running at:

http://localhost:8765/

The app itself was healthy. Codex could access it through direct HTTP requests, but could not attach to the in-app browser automation bridge to close, reload, inspect, or reopen the visible browser tab.

Environment

Product: Codex desktop app
OS: Windows
Local app URL: http://localhost:8765/
Browser surface: Codex in-app browser
Local server: Python app running on localhost:8765
The conversation context repeatedly showed:

# In app browser:
- The user has the in-app browser open.
- Current URL: http://localhost:8765/

User Requests That Triggered The Issue

The user asked Codex to manipulate the visible in-app browser after app updates, including:

close the app in the inapp browser and open the new updated application

Later, after the app had been updated/restarted, the user again asked:

try accessing the browser and close the earlier version and open the latest version

In both cases, the visible in-app browser pane was open at http://localhost:8765/ according to the conversation context.

Expected Behavior

Codex should be able to:

Attach to the currently visible in-app browser pane.
Identify the selected/open tab.
Close or reload the existing tab.
Open a new tab at http://localhost:8765/.
Inspect the DOM or confirm that the updated local app loaded.

Actual Behavior

Codex could not attach to the in-app browser pane.

The browser automation bridge returned:

No active Codex browser pane available

This happened despite the visible app browser context saying that the in-app browser was open.

Timeline / What Happened

1. Earlier browser access had worked

Earlier in the same project, Codex successfully inspected the app through the in-app browser. It was able to see DOM content such as:

NovelTranslations Archive Browser
2128 comments in 52 threads
Browse
Update
Threads
Settings

This suggests browser automation was functioning earlier in the session.

2. Plugin path changed or a stale path was used

At one point Codex attempted to load:

C:/Users/Aniruddha Debnath/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha2/scripts/browser-client.mjs

This failed with:

Module not found

Codex then searched locally and found the current browser client at:

C:\Users\Aniruddha Debnath\.codex\plugins\cache\openai-bundled\chrome\0.1.7\scripts\browser-client.mjs

After switching to the newer path, the module loaded, but attachment still failed during that earlier episode.

3. Attachment still failed after using the current browser-client path

Even after using:

openai-bundled/chrome/0.1.7/scripts/browser-client.mjs

the browser bridge returned:

No active Codex browser pane available

The attempted operation was roughly:

const { setupAtlasRuntime } = await import('.../browser-client.mjs');
await setupAtlasRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get('iab');
const selected = await browser.tabs.selected();

The bridge could not provide an active in-app browser pane.

4. Local app was still reachable

Codex verified that the local app was running by using backend HTTP checks, including:

GET http://localhost:8765/api/summary
GET http://localhost:8765/api/job
GET http://localhost:8765/

Those returned successfully.

Example response from /api/summary:

{
  "thread_count": 100,
  "comment_count": 4401,
  "db_path": "output\noveltranslations_archive.sqlite3"
}

Example response from /api/job:

{
  "running": false,
  "message": "Idle",
  "error": ""
}

So this was not a localhost/server failure. It was specifically a failure to attach to the visible browser pane.

Why This Matters

The user was building and testing a local GUI app. Codex needed to:

reload the app after code changes
inspect the DOM
verify that new controls appeared
close an old tab and open the latest app version
demonstrate browser behavior live to the user

Because the browser bridge could not attach, Codex had to ask the user to manually refresh or reopen the page. This weakens the local GUI development workflow because Codex can verify backend endpoints but cannot reliably verify the actual browser-rendered UI.

Workaround Used

Codex used PowerShell/backend HTTP requests instead:

Invoke-WebRequest -UseBasicParsing http://localhost:8765/api/summary
Invoke-WebRequest -UseBasicParsing http://localhost:8765/api/job
Invoke-WebRequest -UseBasicParsing http://localhost:8765/

This confirmed the app was running, but did not allow interaction with the visible in-app browser UI.

Possible Causes / Questions

This may be caused by one of the following:

The visible in-app browser pane is not registered with the browser automation bridge.
The browser pane exists visually, but agent.browsers.get('iab') cannot find it.
The selected tab state is missing even though context reports an active URL.
The browser plugin/runtime updated from browser-use to chrome, leaving stale bindings or examples.
The in-app browser pane may need to be re-registered after plugin/session changes.
The conversation context and browser automation bridge may disagree about whether a pane is active.

Suggested Improvements

If conversation context reports:

# In app browser:
- The user has the in-app browser open.
- Current URL: ...

then the browser automation bridge should be able to attach to that pane, or should explain why it cannot.

If attachment fails, the error should include diagnostics, for example:

{
  "visible_browser_pane_detected": true,
  "registered_browser_count": 0,
  "selected_tab_available": false,
  "bridge_status": "disconnected",
  "suggested_recovery": "reopen in-app browser pane or re-register browser"
}

Provide a recovery API/tool call that reconnects the visible browser pane to the automation bridge.
Avoid stale plugin path issues by exposing the current browser-client path or abstracting it away from the agent.
Clarify whether agent.browsers.get('iab') means:

the visible in-app browser pane,
a hidden/background in-app browser session,
the most recently used in-app browser session,
or any in-app browser session registered with the bridge.

Repro Steps

Open a local web app in Codex’s in-app browser:

http://localhost:8765/

Confirm the conversation context says:

# In app browser:
- The user has the in-app browser open.
- Current URL: http://localhost:8765/

Ask Codex to close, reload, or reopen the in-app browser tab.
Codex attempts to attach via the browser client.
Observe error:

No active Codex browser pane available

Confirm the local app is still reachable via direct HTTP request.

Severity

Medium-high for local GUI development workflows. The user can continue manually, but Codex cannot reliably verify or interact with browser-rendered local apps.

Relationship To The Main Issue

This appears related to the main issue, but not identical:

Main issue: automation controls a hidden session while the user-visible panel remains blank.
This comment: user-visible pane exists according to context, but the bridge reports no active pane and cannot attach.

Both point to a broader synchronization problem between the conversation context, visible in-app browser UI, tab selection, and the automation bridge.

Adding a related observation from September 7, 2026: a visible in-app browser tab was inaccessible to delegated browser helpers during a Codex desktop voice conversation on Linux.

Observed workflow

Open Amazon.es search results for scooters in the visible in-app browser.
Ask Codex to click a product by its position in the displayed grid.
Explicitly select @Browser and request a check of that existing tab.
Browser actions are delegated to a helper. The helper connects to Codex In-app Browser, but both browser inventory and explicit tab listing return zero accessible tabs.
Repeat with a fresh helper created after the Browser selection: the result is still an empty tab list.

The desktop UI and conversation's browser context reported one open Amazon tab throughout the later checks. No product was clicked. An earlier helper could search successfully in its own background browser, but that did not establish control of the user's visible tab.

Diagnosis and limits
Command-line checks found the browser components installed and enabled. Inspection of the installed browser runtime indicated that helpers use their own task identity for browser discovery and requests. This suggests session isolation explains this particular failure; it is not confirmation of the same underlying defect as the original report. No configuration changes or attempts to bypass that isolation were made.

Expected behavior
A shared browsing workflow should either provide a supported way for the authorized executor to work with the exact user-visible tab, or clearly report that delegated helpers cannot access it before repeatedly asking the user to attach Browser and retry.

This currently blocks instructions such as selecting an item by its visible row and column. Is there a supported workflow for shared visible-tab control when browser actions are delegated, or should this be tracked separately?

In-app browser automation can control hidden session while visible panel shows Nothing here yet #22678

Description

Summary

Environment

Reproduction Scenario

Expected Behavior

Actual Behavior

Root Cause Found During Session

Related API Ergonomics Bug

Documentation / Discoverability Issue

Additional Browser-Related Failures Observed

Intermittent inability to attach to the in-app browser

Stale browser client path confusion

Automation state and visible user state can diverge

Why This Matters

Suggested Fixes

Minimal Working Recovery Code

User-Facing Symptom

Activity

debnathaniruddha89-design commented on May 14, 2026

Additional related failure mode: visible in-app browser pane existed, but automation bridge could not attach

Summary

Environment

User Requests That Triggered The Issue

Expected Behavior

Actual Behavior

Timeline / What Happened

1. Earlier browser access had worked

2. Plugin path changed or a stale path was used

3. Attachment still failed after using the current browser-client path

4. Local app was still reachable

Why This Matters

Workaround Used

Possible Causes / Questions

Suggested Improvements

Repro Steps

Severity

Relationship To The Main Issue

karavatsky commented on Sep 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions