codex - 💡(How to fix) Fix Codex App in-app browser should support multiple visible tabs

What variant of Codex are you using?

Codex Desktop App for macOS

What feature would you like to see?

Please add support for multiple visible tabs in the Codex Desktop App in-app browser panel.

Current behavior:

The Codex Desktop App in-app browser currently behaves like a single visible browser surface. During normal agent work, that means the user and agent have to keep reusing the same visible page even when the workflow naturally involves several pages.

For example, in one Codex thread I often want to keep these open at the same time:

• a local development app on localhost
• a GitHub issue or PR
• project documentation
• a preview or production page for comparison
• a login/auth page or admin dashboard

With the current single visible browser surface, each new page replaces the previous one. That loses useful page state, makes comparison harder, and increases the chance that the agent navigates away from something the user still needed.

Expected behavior:

The in-app browser panel should support a compact browser-style tab strip.

Minimum useful behavior:

• create a new in-app browser tab
• switch between visible in-app browser tabs
• close an in-app browser tab
• preserve each tab's URL, title, loading state, and back/forward history while the thread is active
• make the selected tab visually clear to the user
• make the selected tab explicit to browser automation/tooling, so agent actions target the intended page

Nice-to-have behavior:

• rename a browser tab, or use the page title by default
• open a link in a new in-app browser tab
• restore active browser tabs when returning to the same thread
• show a small loading/progress state per tab

Why this would help:

This would make the in-app browser much more useful for real Codex Desktop workflows, especially when the agent is testing or debugging a local app.

Common examples:

• keep a local app open while Codex reads related docs
• compare preview and production behavior without constantly navigating back and forth
• let the user complete login in one tab while Codex keeps the target app or issue open in another
• keep GitHub, app UI, and documentation available during a fix/verify loop
• reduce accidental state loss when a browser task needs to inspect a different page

Suggested implementation direction:

I understand that the full desktop UI implementation may not be in the public openai/codex repo. Still, the public/bundled browser tooling already appears to have a logical tab model, so this could likely be implemented as a small UI/state layer rather than a brand-new browser abstraction.

A small first slice could be:

1. Add a per-thread in-app browser tab model in the Desktop App shell.
2. Render a compact tab strip above the existing in-app browser view.
3. Track selectedTabId explicitly.
4. Reuse the existing browser/backend tab operations for create/list/select/claim/close where possible.
5. Continue defaulting agent browser actions to the selected visible tab.
6. Include the selected tab id in browser-tool state/diagnostics so mismatches are easier to debug.

Example shape:

type InAppBrowserTab = {
  id: string;
  title: string;
  url: string;
  isSelected: boolean;
  isLoading: boolean;
  canGoBack: boolean;
  canGoForward: boolean;
};

Possible small UI wiring:

type InAppBrowserTabsState = {
  tabs: InAppBrowserTab[];
  selectedTabId: string | null;
};

function selectBrowserTab(tabId: string) {
  // Mark the tab as selected in Desktop UI state.
  // Then tell the browser backend/tooling layer that this is the active tab.
}

function createBrowserTab(initialUrl?: string) {
  // Create a browser tab through the existing browser tab operation.
  // Add it to the Desktop tab strip and select it.
}

function closeBrowserTab(tabId: string) {
  // Close the backend tab if possible.
  // Remove it from the tab strip.
  // Select a neighboring tab if the closed tab was active.
}

If the public repo is the wrong place for the Desktop UI code, the public codex-rs/app-server / browser-tooling contract still seems like the right place to keep the agent-visible active-tab state explicit. The key part is that the Desktop UI and the agent browser tools should agree on the same selected tab.

Risks and constraints:

• Avoid agent confusion: every browser action should have one clear active tab.
• Avoid privacy surprises: background tabs should not be silently inspected unless selected or explicitly targeted.
• Preserve existing URL/security policies for every tab.
• Keep resource usage bounded; inactive tabs may need a small limit, suspension, or cleanup policy.
• Do not turn the in-app browser into a full general-purpose browser. The goal is just enough tab support for agent workflows.
• Keep this separate from external/system browser profile support. That is useful too, but this request is specifically about multiple tabs in the built-in in-app browser.

Additional information

Codex App Version: 26.513.20950 (2816)

Codex bundle identifier: com.openai.codex

Subscription: GPT Pro

System: Darwin 24.5.0 arm64 arm

Platform: macOS, Apple Silicon

Existing issues checked before filing:

• #18778 asks for active running tabs at the app level. This request is narrower: multiple visible tabs inside the in-app browser panel, plus clear active-tab behavior for browser tooling.
• #19955 asked for a tabbed chat/session interface and was closed as a duplicate of #18778. This request is not about chat/session tabs.
• #22538 reports a related tooling problem: terminal tabs can exist in the UI while the assistant sees only one terminal context. This is a useful caution for browser tabs: the UI-selected tab should be explicit to the tooling layer.
• #22808 asks for touchpad horizontal scroll for browser tab back/forward navigation. That is browser-tab behavior, but not multiple visible browser tabs.
• #21145 asks for external/system browser profile support. That is separate from adding multiple tabs to the built-in in-app browser.