Support multiple notes open at once (tabs or windows)

[nyashkn]

One note per window with back/forward navigation (#111) works well for reading, but not for running several agent conversations at once.

Concretely: I keep three notes in play, each with its own back-and-forth with Claude Code. Only one is visible at a time, so I lose the thread on the other two.

Either shape would solve it — tabs within a window, or multiple windows over one workspace.

open -n -a Hubble is not a workaround: two instances over the same folder risks clobbering while the sync engine is WIP.

[github-actions]

Labeling this needs-discussion — the pain is real and not tracked elsewhere, but the request offers two very different shapes and the desktop shell is single-document from Electron main down to the renderer store, so there's no bounded implementation path yet.

What the code says today:

• Electron main holds one mainWindow singleton (apps/desktop/electron/main.ts:133), routes every event through a single sendToRenderer, persists one window-size.json, keeps global menuState, and takes a single-instance lock where a second launch just forwards a path to the existing window (apps/desktop/electron/main.ts ~1844-1857). Multiple windows means making window identity a first-class concept across IPC, watchers, zoom, menus, and grants.
• The renderer store has exactly one document slice with one currentPath/diskContent/conflict state (apps/desktop/src/store/state.ts), one persisted localStorage blob, and back/forward history keyed per workspace rather than per pane (apps/desktop/src/store/history.ts). Tabs means per-document buffers, per-pane history, and a persistence-schema change.
• The terminal panel already has multi-session tabs (apps/desktop/src/components/TerminalPanel.tsx), so several agent conversations can run side by side today; what's missing is per-note editor context, and whichever shape wins has to decide how terminal sessions bind to notes/tabs/windows.

No duplicate found: #111 (back/forward) is closed and is what the report builds on; nothing else tracks tabs or multiple windows.

Open questions before this is implementable:

1. Tabs or windows? They have different costs and are not interchangeable — tabs are renderer-only; windows require reworking main-process singletons. Picking one is the blocker.
2. If tabs: is history per tab or still per workspace? What persists across restart — open tabs, or just last-opened file?
3. If windows: one workspace per window, or independent workspaces? How do the file watcher, grants, and the WIP sync engine behave with two windows on the same folder (the same clobbering risk the report raises for open -n)?
4. How do notes-with-unsaved-edits and the existing disk-conflict flow behave in a background tab/window?
5. How does the terminal panel scope — one per window, one per tab, or shared?
6. Is split view (two notes visible at once) in scope, or strictly one visible note with fast switching? The stated use case (three agent threads) may be served by fast switching plus per-note terminal sessions, which is much smaller.

@nyashkn — if you have a preference between tabs and windows for your three-agent workflow, and whether you need two notes visible simultaneously or just to not lose the thread when switching, that would narrow this a lot.

---

Triaged by a Warp Factory agent.

[nyashkn]

Tabs — the mental model is VS Code: four files open, four tabs, click to switch. One note visible at a time, no split view.

• Tabs, not windows — nothing here needs a second window
• History per tab — each tab keeps its own back/forward
• One terminal session per tab, bound to that note
• Dirty state on the tab, existing disk-conflict flow unchanged
• Fast switching is enough — that's the whole ask

The pairing is the problem: terminal tab 3 is talking about a note I can't see. Binding one session per tab fixes it without touching Electron main.

[MonisMS]

Now that the shape is settled tabs, per-tab history, one terminal session per tab, no split view is this ready to move to ready-to-implement? Happy to take it. Please confirm the approach for the store change (per-document buffers replacing the single document slice) before starting, in case you have a preferred shape there.

[nyashkn]

Yes — per-document buffer per tab is the shape. Each tab's buffer carries its own dirty/conflict state (existing disk-conflict flow, just scoped to the tab instead of the single document slice). Go ahead.

[MonisMS]

@bholmesdev — this is still needs-discussion and I don't want to build the UI in the wrong direction, so a quick check first.

@nyashkn's list further up is a clear spec and I'm building to it: tabs, one note visible, history per tab. No complaints there.

The one thing I'd like a second opinion on is the store shape. I'd asked whether per-document buffers were the way to go and nyashkn was good enough to answer, but that's really a question for whoever owns this store, and having spent some time in it I think there's a cheaper path.

The snag is that the single-document assumption is load-bearing in reads, not just writes. savePathContentNow bails on current.currentPath !== path, the auto-title liveness check in titleManagement.ts is viewerStore.get().currentPath !== session.path, and updateMovedLinks takes the open file's content from the draft and every other file from disk, with a comment explaining that disk is stale for the file being edited. Today all of those mean "the only document". With a buffer per tab they'd quietly come to mean "the focused document" — a background tab stops saving, auto-titling dies on a note you've switched away from, and a folder rename rewrites links into a background tab from stale disk content, dropping whatever was unsaved there. None of it fails to compile. There's also the 120ms autosave debounce — two tabs on one file is two timers writing that file.

What I've prototyped instead is a tab that holds a path and its own back/forward trail, where activating one does what clicking a sidebar row already does: save, then load. DocumentState and the single file watcher stay as they are.

That costs something real, and it costs one of the things nyashkn asked for. Undo history and view mode reset when you switch tabs, and there's no per-tab dirty dot. With autosave I'm not sure the dot earns its place, but I didn't want to quietly drop it without asking.

So: is that trade worth it to you, or would you rather have buffers and the work of making those reads tab-aware?

Also, is one terminal session per tab in scope here? It's the part nyashkn actually needs, but retargeting a running session looks like main-process work, so I'd rather do it properly as a follow-up than bolt it on.

Store layer is done and passing, no UI yet. I can push it as a draft if that's useful, or park it if you'd rather take this a different way.

[nyashkn]

@MonisMS sorry for the slow reply — was heads-down elsewhere.

Take the cheap path: save-then-load per tab switch, no per-document buffers. That matches the original ask better than I stated it — "fast switching" was the actual requirement, not live background state. Given autosave already fires on a 120ms debounce, the dirty dot doesn't carry much signal anyway — fine to drop it. Undo/view-mode reset on switch is an acceptable cost too.

Terminal-per-tab: yes, in scope, but agreed — do it as a follow-up PR, not bolted onto this one. Keep this PR to the store/tab-switch mechanics.

Push the draft whenever's convenient, happy to look.