Codex App in-app browser should support multiple visible tabs

[rogierx]

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:

• Show active running tabs on top similar to browser tabs #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.
• Add tabbed chat/session interface to Codex Desktop #19955 asked for a tabbed chat/session interface and was closed as a duplicate of Show active running tabs on top similar to browser tabs #18778. This request is not about chat/session tabs.
• Codex App terminal tool only exposes one terminal tab despite multiple UI 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.
• Support touchpad horizontal scroll for browser tab back/forward navigation #22808 asks for touchpad horizontal scroll for browser tab back/forward navigation. That is browser-tab behavior, but not multiple visible browser tabs.
• Feature request: allow Browser use to use an external/system browser profile #21145 asks for external/system browser profile support. That is separate from adding multiple tabs to the built-in in-app browser.

[aderici]

I want to open multiple tabs to simulate multiple users running a flow in my application. so tab 1 login with user x, tab 2 login with user y. x submits record y receives it etc.

[aguynamedben]

+1, my use case: I have 3-4 SaaS tools that all work together, and I want log Codex into each of them so Codex can work and correlate information across them.

[MalikElate]

its one of the last features keeping me on cmux

hope they add this soon

[dietervdw-lovable]

Yep was looking to switch from cmux but I want to be able to have the ticket + the PR open at the same time. Really silly restriction.

[AdamGustavsson]

This would be very useful for Google tag manager preview. This is a common task in digital marketing.
I use Codex to modify tagging for websites with GTM. the preview mode requires 2 tabs.

1. One for the tag assistant showing what tags triggered.
2. One for the site being previewed.
   codex need to click around on tab 2 and see the result in tab 1.
   This is the missing piece that I have to do manually as of now

[thebrownproject]

Adding another +1 from a slightly different angle: I want Codex Desktop to become the main interface I work through, where I ask the agent to navigate instead of clicking around manually. In that model, multiple in-app browser tabs are not just convenience UI. They are the agent/user shared working memory.

A typical workflow wants GitHub, a preview deployment, production, docs, auth/admin pages, and maybe Vercel/observability open at the same time. With one visible browser surface, every agent navigation destroys some context or forces the user to keep mentally tracking what was replaced. That makes Codex feel like a preview pane rather than an actual browser workspace.

The important product point for me: this does not need to become a full personal browser. It just needs enough per-thread tab support that the user can say things like "go back to the GitHub tab", "compare this with the preview tab", "keep the docs open while you test", or "use the admin tab to check the result".

I would also strongly support making the selected visible browser tab explicit in the browser tooling contract. The user should be able to see which tab Codex is about to operate on, and Codex should not have to infer it from hidden state. That would make browser automation feel much safer and much closer to the agent-native interface this app seems to be heading toward.

[0xdevalias]

In that model, multiple in-app browser tabs are not just convenience UI. They are the agent/user shared working memory.

@thebrownproject While I don't necessarily disagree with any of this. Have you used the Chrome integration or similar? As that may get you a lot of what you want from it already without needing to wait / hope on the internal browser feature being made far more 'real browser' like.