Proposal: native multi-window support for independent threads

[abhinavthukral28]

Proposal: native multi-window support for independent threads

Related requests: #2399 and #3596.

I have a working prototype of native multi-window support and would like to confirm the desired scope and integration shape before opening a pull request. The rebased, review-ready prototype is available on abhinavthukral28:feat/multi-window-contribution.

User experience

• File → New Window opens another T3 Code window.
• A thread can be opened directly in a new window.
• Each window can navigate independently while sharing the same configured projects, connections, and settings.
• Existing deep-link and second-instance activation behavior routes to an appropriate window.
• Shared interactive surfaces use ownership leases so two windows do not simultaneously edit the same composer, file, terminal, or preview session.

Implementation outline

• Replace the single-window assumption with a desktop window registry and explicit primary-window selection.
• Route IPC using the authenticated sending renderer instead of a process-wide window singleton.
• Synchronize renderer-side settings and connection catalog changes across windows.
• Coordinate shared resources with per-surface interaction leases and takeover notifications.
• Keep preview tabs alive when one renderer releases them without closing the shared browser tab.

The prototype has been rebased onto current main. Focused tests cover window creation and routing, IPC sender forwarding, lease lifecycle and takeover, stale-response handling, settings and connection synchronization, preview registration, and shared preview lifetime. The affected desktop, web, contracts, and SSH packages typecheck successfully.

Review findings and proposed PR shape

A pre-PR ownership review found several areas that should be hardened before treating the full feature as production-ready:

• Settings and connection writes need revisioned or atomic mutations to avoid last-writer-wins races between windows.
• Composer, file, terminal, and preview ownership should be enforced at the command/write boundary, not only by disabling renderer controls.
• Preview capture/Picture-in-Picture and SSH password prompts should follow the window that owns the operation rather than a legacy primary-window singleton.
• In-flight file saves and stale lease responses need fencing when ownership or the active thread changes. The stale lease-response case is already fixed and covered by a regression test.

To keep review manageable, I suggest a small stack rather than one large PR:

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 this staged approach, a smaller first pass limited to opening independent read-only windows, or no implementation PR at this time?

If there is interest, I will add clean-profile before/after screenshots and a short interaction video to the UI-changing PRs. The separate unpublished desktop-build/SSH workaround used while testing is intentionally out of scope and will not be included.

[juliusmarminge]

Closing as a duplicate of the existing multi-window request: #6740 (converted from #2399). Please continue the prototype / PR-shape discussion there.

Related but distinct (in-window split / pop-out): #6746 (from #3596).