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

1. User has the Codex in-app browser panel open.
2. User-visible panel shows Nothing here yet.
3. 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/');

1. Automation succeeds and can read page title/body text.
2. Codex reports seeing the app.
3. 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

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

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

1. Provide clearer error messages when Codex controls a hidden browser session.
2. Ensure compacted context or internal examples do not point to stale browser-client paths.
3. 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.