[Feature]: Multiple Window Support

[tyler6204]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

Desktop app / window management

Problem or use case

I want to use multiple t3code windows at the same time so I can keep separate projects, threads, or tasks open side by side. Today, the app appears to behave like a single-window experience, which makes it harder to compare work, monitor a long-running agent task, or switch between independent coding sessions without losing focus.

Proposed solution

Add support for opening multiple app windows or instances. Each window should be able to show a different project or thread, while preserving the normal session state for that window.

Useful behavior would include:

• A menu item or command to open a new window.
• The ability to open different projects or threads in separate windows.
• Correct session isolation so actions in one window do not unexpectedly affect another.
• Window restoration where practical after app restart.

Why this matters

Multiple window support would make t3code better for real coding workflows where several tasks need to stay visible at once. It would reduce context switching and make it easier to run one agent task while reviewing or continuing another.

Smallest useful scope

A first pass only needs to support opening a second independent window for the app and allowing that window to navigate to a different project or thread.

Alternatives considered

The current workaround is to run one session at a time and manually switch between threads or projects. That works for simple cases, but it slows down workflows that need parallel visibility.

Risks or tradeoffs

Multiple windows may require careful handling of shared provider sessions, file watchers, app-level shortcuts, and persisted UI state. The app should avoid duplicate provider actions or cross-window state leaks.

Examples or references

Comparable desktop coding tools support multiple windows so users can keep separate projects or workstreams open independently.

Contribution

I would be open to helping implement this.

[dthinkr]

We’d also really value multiple-window support. Keeping a long-running agent thread visible in one window while reviewing or steering another—potentially in a different project—would make parallel workflows much easier to manage. Even a minimal second independent window with preserved thread state would be very useful.

[Wiktor102]

That would make virtual desktops an actually useful workflow where you have a different project open on each desktop.

[jsonMartin]

Agreed - this feature would be a game changer for virtual desktops.

It could work like Linear - one application can view anything, but you can also open new windows which each have their own UI scopes. In T3 Code, each different window could have a different project selected with it's own independent UI state, etc.

[abhinavthukral28]

Thanks for redirecting this to the canonical thread. I have a rebased prototype available at abhinavthukral28:feat/multi-window-contribution.

The current prototype adds:

• File → New Window and open-thread-in-new-window actions.
• Independent navigation per window with shared projects, connections, and settings.
• A desktop window registry, primary-window selection, and activation/deep-link routing.
• Authenticated sender-aware IPC routing.
• Per-surface interaction leases for shared composers, files, terminals, and previews.
• Cross-window settings, connection catalog, and prompt synchronization.

It is rebased onto current main. The focused suite passes 144 tests, affected package typechecks pass, and the desktop production build succeeds. A coverage pass also found and fixed stale lease-takeover responses and incorrect secondary-window preview registration.

Before opening a PR, I reviewed the full ownership model and found several areas that should be hardened: atomic/versioned settings and connection mutations, command-boundary enforcement for shared resource leases, fencing pending file writes during takeover, and routing preview capture/PiP plus SSH password prompts to the operation's owning window.

Because the complete prototype is roughly 2,000 added lines, I do not want to drop it as one large unsolicited PR. My proposed stack is:

1. Window foundation: registry, lifecycle, activation routing, New Window, and open-thread-in-new-window.
2. Shared state: versioned settings/connection synchronization and renderer registration.
3. Resource ownership: command-boundary leases for composer, files, terminals, and previews, including owner-window lifecycle routing.

Would maintainers prefer that staged implementation, a narrower first PR limited to independent read-only windows, or no implementation PR yet? I will include clean-profile before/after screenshots and a short interaction video with any UI-changing PR. The unrelated SSH/build workaround used during local testing is intentionally excluded.

[abhinavthukral28]

One additional note after checking for overlapping work: I searched the public upstream PRs and discussions, plus indexed public fork code and commits, and did not find another complete native multi-window implementation for T3 Code.

The closest related work I found is:

• Discussion #6746, where gbretas described an in-window multi-pane approach, but I could not find a public implementation branch. That work is complementary rather than the same native-window model.
• PR #9444, which improves the separate preview/Picture-in-Picture window only.
• PR #2999, which implemented server multi-instance support and left Electron multi-window as a follow-up specification.
• Merged PR #8824, which provides app activation and window-focusing infrastructure that the prototype extends into actual per-window routing.

So, based on the public work currently visible, feat/multi-window-contribution appears to be the first end-to-end native implementation covering independent app windows, thread routing, shared state, and interaction ownership. I am happy to coordinate with any unpublished or in-progress implementation and adapt the proposed PR split to avoid duplicating work.

[Wiktor102]

@abhinavthukral28 Seeing that there are PRs open here with over a hundred thousand lines of change, I think this can safely be filed as one PR.

[olafura]

This gist is a demonstration of how this feature could be built or customized with the Qt/QML branch. It is an example to try and adapt, not a complete implementation of the discussion request or a feature shipped in upstream T3 Code.

This demonstrates the extensible QML approach in #10708 with working independent desktop windows. The gist adds New window and Ctrl+Alt+N to the default Qt shell.

Each extra window is a normal top-level window with independent navigation, composer drafts and panel layout. Pairing, app-wide preferences and durable server state remain shared; two windows on the same thread still share that thread's terminal sessions. There is no exclusive editing lock.

Closing one extra window leaves the others open. Closing the primary window closes its extras. Automatic window/route restoration after restart is not implemented.

Working demonstration gist and setup.

These are two separate windows running at the same time on workspace 5, captured individually without switching the desktop. Both use demo conversations.

First window, settings design and an unsent planning draft:

Second window, token validation and a different unsent implementation draft:

Verified that navigation and draft edits in the second window leave the first unchanged, and closing the second keeps the first window and its draft intact.

Code and checks assisted by Codex.

[olafura]

Sorry for the lack of context this is showing how using this technique in the linked discussion would help with your issue #10708