Multi-Window Support for macOS

Open 💬 16 comments Opened Feb 25, 2026 by Indekkusu545
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

App

What feature would you like to see?

1. Executive Summary

Introduce multi-window capability to the Codex desktop application. This feature will allow users to open multiple independent instances or project windows, enabling seamless multitasking across different macOS Spaces (Virtual Desktops).

2. Problem Statement

Currently, Codex is limited to a single-window interface. For software engineers who manage multiple workstreams simultaneously (e.g., frontend development, backend API testing, and documentation), the single-window constraint creates a productivity bottleneck.

  • Workflow Disruption: Users cannot view two different parts of a project or two separate projects in different macOS Desktops.
  • Navigation Fatigue: Switching between tasks requires constant clicking within the same window, rather than utilizing the native macOS "Three-finger swipe" to move between dedicated workspaces.

3. Proposed Solution

Implement a native multi-window architecture that allows Codex to spawn independent windows.

  • New Window Creation: Add a "New Window" option under the File menu and support the standard Cmd + N shortcut.
  • Independent Instances: Each window should be able to load different project folders or files independently.
  • macOS Integration: Ensure windows are recognized as individual entities by macOS, allowing them to be assigned to different "Spaces" or used in "Split View" mode.

Additional information

_No response_

View original on GitHub ↗

16 Comments

etraut-openai contributor · 4 months ago

Recent versions of the app have introduced the ability to "pop out" threads into their own window. Click on the button in the upper right of the main window to create a separate window.

Indekkusu545 · 4 months ago

Cool. But I still think multi-window support should be needed at least at the project level, because there should be multiple threads in the same project, and it would be quite troublesome to pop out every time a thread is opened.

Indekkusu545 · 4 months ago

When using the CLI, you can benefit from the terminal's built-in multi-window functionality and easily start a new thread using /clear.

etraut-openai contributor · 4 months ago

OK, I'll keep this feature request open, and we can see if it gets upvotes from the community.

mwood23 · 4 months ago

My use case is that I normally have workspace per project so this limits how many times I can use codex. The popup window doesn't work too well either because it duplicates across all workspaces. I've been using the opencode ui for one project and codex as another for a workaround for now. If you all have a beta/canary release I'd happily roll that for one and the stable codex for the other if that's possible.

Ga68 · 3 months ago
Recent versions of the app have introduced the ability to "pop out" threads into their own window. Click on the button in the upper right of the main window to create a separate window.

It appears that this feature was removed on the mac app recently. Is that true? I don't have it on mine anymore ... and I miss it.
@etraut-openai

jaewun · 3 months ago

Yeah looks like you can still pop out a mini window from the new chat page, and even move that chat back into the main window, but there's no option to pop an existing chat out into a mini window. Please fix 🙏

sk-ruban · 3 months ago
It appears that this feature was removed on the mac app recently. Is that true? I don't have it on mine anymore ... and I miss it. @etraut-openai

Looks like its only possible for new chats right now

<img width="369" height="133" alt="Image" src="https://github.com/user-attachments/assets/4bece32c-538b-40da-8837-dae0d2449fb7" />

zaczacariah · 3 months ago

Glad its back - but this really needs a shortcut and not just for new chat. Feels obvious to me?

sampl · 3 months ago

This is a big one for me. Virtual desktops (mapped to worktrees) are a super common workflow, but IMO mini windows don't solve the issue because they're too closely tied to tasks:

  • To start a new task (context window) you need a new mini window, but you can't create a new task/mini window from an existing mini window
  • New mini windows don't remember the position or space (virtual desktop) of the previous mini window so have to be positioned from scratch

Mini windows are also missing important UI:

  • Other threads in the worktree, including history
  • Badges that indicate another thread needs the developer's attention
  • Searching threads

Multiple windows is a common pattern in IDEs like vscode etc, so IMO supporting them here makes sense.

Another option could be opening a _Project_ in a mini window rather than a chat/task/thread. This still doesn't alert the dev about which other threads need their attention though.

Thanks for considering this!

sampl · 3 months ago

Looks fixed! Thank you :)

cmd+shift+N opens a new window

or in the menu bar:

<img width="351" height="202" alt="Image" src="https://github.com/user-attachments/assets/6c7f7e0c-6a2b-4c93-bf8c-137cb1571a13" />

zaczacariah · 3 months ago

Legendary move

simonhsze · 2 months ago

This is close to what I want, but I’m really looking for more than just multiple windows.

I want to use Codex like a workspace for supervising multiple agents. Usually that means 4-6 active tasks at once, sometimes in one repo, sometimes across several projects.

Right now the app feels too single-threaded for that. I can switch between threads, but I can’t comfortably monitor several tasks side by side.

What would help a lot:

  • multiple task windows/panels
  • a way to see several active agents at once
  • quick visibility into progress, diffs, terminals, and status
  • some kind of project/board view for active work

I want Codex to feel more like an agent workbench, not just one chat at a time.

IsaacCheng9 · 1 month ago

@simonhsze I completely agree – multiple windows are good for those who want the UI to be duplicated, but for compactness it would be much nicer if we had the option to have multiple panes, similar to the implementations in Ghostty and the various terminal emulators.

isai-nrobot · 1 month ago

I am seeing a related multi-window problem in Codex for macOS: even when I open more than one Codex window, the left navigation/sidebar state is not independent per window.

What happens

If I collapse or expand a project group in the left sidebar in one Codex window, the same project group is collapsed or expanded in the other Codex windows too.

So the windows may be visually separate, but the sidebar/navigation UI state appears to be shared globally across the app.

Why this matters

The main reason to use multiple windows is to keep different workstreams visually and mentally separated. For example:

  1. Window A: one project or agent thread
  2. Window B: another project or agent thread
  3. Window C: triage or review work

In VS Code, each window has independent UI state. I can collapse folders, focus a workspace, and shape the sidebar differently per window. That makes multiple windows genuinely useful.

In Codex, if sidebar state is shared across all windows, the windows are not truly independent from a workflow perspective. It becomes harder to distinguish projects, agents, and active workstreams quickly, especially when supervising multiple Codex threads in parallel.

Expected behavior

Each Codex window should preserve its own local navigation/sidebar UI state, including:

  1. Expanded/collapsed project groups
  2. Current sidebar focus or selection where applicable
  3. Visible navigation context
  4. Ideally, the active project/worktree context per window

Actual behavior

Sidebar expansion/collapse state appears to be shared across all open Codex windows.

Suggested fix

Treat sidebar/navigation state as window-local rather than app-global. Multiple windows should behave more like independent workspace windows in VS Code.

This would make Codex much more useful for parallel agent supervision, which seems aligned with the app’s stated purpose of working across projects and Codex threads in parallel.

0xdevalias · 27 days ago

It feels like this issue is starting to get crowded up by things that really should be seperate independent issues IMO; and by my read of it, this issue should probably be closed as the main actual original request seems solved to me.

---

Looks fixed! Thank you :) cmd+shift+N opens a new window

This is pretty much the answer to 'multi-window support', and it has been supported for quite a while; which I personally would say is a reason that @etraut-openai should probably close this issue as done.

---

This is close to what I want, but I’m really looking for more than just multiple windows.
I can switch between threads, but I can’t comfortably monitor several tasks side by side. What would help a lot: * multiple task windows/panels

@simonhsze This is kind of confusing, because you say it's "close to what I want", but that you want more, and then the thing you name as 'more' is what is already supported (multiple windows that you could put side by side)

---

multiple windows are good for those who want the UI to be duplicated, but for compactness it would be much nicer if we had the option to have multiple panes, similar to the implementations in Ghostty and the various terminal emulators.

@IsaacCheng9 I do tend to agree with you on this, but I would suggest that this issue isn't really the place to raise it, as it's not very visible hidden away as a 'tangential at best' comment on this thread. The way I would describe this sort of a feature would be for a Codex window to support multiple 'thread tabs' being open within it at the same time; which I believe there are already existing / better issues for, eg.:

---

I am seeing a related multi-window problem in Codex for macOS: even when I open more than one Codex window, the left navigation/sidebar state is not independent per window.

@isai-nrobot This is also seemingly a 'tangentially related at best' sort of thing that would be better raised as it's own independent issue for visibility, not lost hidden away as a comment here.