add TUI multi-session registry and focused-session root projection#13775
add TUI multi-session registry and focused-session root projection#13775harryalbert wants to merge 3 commits into
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
b877cf4 to
a725a0d
Compare
db49817 to
07f43ac
Compare
a725a0d to
7fde057
Compare
0503bbd to
6cf263f
Compare
7fde057 to
289a5d1
Compare
6cf263f to
70fcf39
Compare
289a5d1 to
cbbd8d0
Compare
70fcf39 to
ae11307
Compare
cbbd8d0 to
6bb0618
Compare
ae11307 to
78d63d7
Compare
6bb0618 to
6a04f77
Compare
78d63d7 to
6dceea3
Compare
6a04f77 to
1e9b80f
Compare
6dceea3 to
18c23d5
Compare
063d148 to
97603f3
Compare
08a5d3e to
e9d064f
Compare
97603f3 to
b030f4f
Compare
b030f4f to
6a48d86
Compare
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This PR introduces a process-local TuiSessions registry, moves RootTuiView to project only the focused retained session, and updates TUI session focus/exit-summary handling so background sessions stay alive without participating in rendering or input routing.
Concerns
- No blocking correctness, security, or spec-drift concerns found in the annotated diff.
- The provided
spec_context.mdcontains no approved or repository spec context, so there were no external spec commitments to compare beyond the PR's own checked-in TECH notes.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
| /// Whether the authenticated terminal session has been created yet. Mirrors the | ||
| /// GUI root view's `AuthOnboardingState` split between the pre-session login gate | ||
| /// and the live terminal session. | ||
| enum RootTuiState { |
There was a problem hiding this comment.
As discussed offline, we should keep the Auth vs Terminal RootTuiState
| TuiSessions::new(driver, window_id, exit_summary, resume_token) | ||
| }); | ||
| root.update(ctx, |_, ctx| { | ||
| ctx.subscribe_to_model(&sessions, |_, _, _, ctx| ctx.notify()); |
There was a problem hiding this comment.
We should subscribe to explicit events
| } | ||
|
|
||
| /// Returns the window and exit-summary handle used to create session views. | ||
| pub(crate) fn surface_context(&self) -> (WindowId, TuiExitSummaryHandle) { |
There was a problem hiding this comment.
Why do we need to retain and return a WindowId here? I don't think we really need that for TUI no?
6a48d86 to
d97af3b
Compare
194fd82 to
a37739b
Compare
d97af3b to
eb8c75e
Compare
a37739b to
d2f380b
Compare
TuiSessions (SingletonEntity) owns all session cores with insertion order, focus, and Added/Removed/FocusChanged events; all session creation flows through it. RootTuiView becomes a projection: a lazy, retained view cache keyed by session id, rendering and routing input to only the focused session. The login bootstrap registers session 0 focused, and the terminal manager handle moves onto the session core. Co-Authored-By: Oz <oz-agent@warp.dev>
eb8c75e to
9fcd29b
Compare
d2f380b to
91a1b4a
Compare

Description
Adds
TuiSessions, a process-local registry for retaining multiple live TUI terminal sessions and selecting which one is foreground. EachTuiSessionowns a completeTuiTerminalSessionViewplus the terminal manager that keeps its PTY and event loop alive. The eagerly-created view ID is also the session ID and shared-modelterminal_surface_id, so the TUI does not introduce a second identity mapping.RootTuiViewbecomes a projection ofTuiSessions::focused_session()rather than the owner of one authenticated terminal child. Only the focused view is returned fromchild_view_ids()and rendered into the responder chain; background views remain alive without participating in layout or input routing. Login bootstrap creates and focuses the initial session through the same registry path that later orchestration children use.Session activation restores the focused view's current input owner and exit-summary token. Subsequent PTY, blocker, CLI-subagent, and conversation-restore focus transitions are guarded by registry focus, preventing background sessions from stealing window focus or replacing the foreground resume hint.
This PR is the multi-session ownership primitive consumed by the local-child orchestration PR above. It intentionally does not add session navigation UI, persistence, or child-agent materialization.
Ownership and data flow
Linked Issue
CODE-1822 — Orchestration
Review guide
crates/warp_tui/src/session_registry.rs— session identity, retained view/manager ownership, focused-session selection, activation, and events.crates/warp_tui/src/root_view.rsandcrates/warp_tui/src/session.rs— focused-view projection and the unified login/session-creation path.crates/warp_tui/src/terminal_session_view.rs— focus-neutral construction, activation, background focus guards, and focused exit-summary ownership.specs/code-1822-tui-multi-session/TECH.md— as-built ownership model, non-goals, and validation contract.Testing
cargo check -p warp_tui --testsNo user-facing changes yet
Agent Mode
CHANGELOG-NONE
Co-Authored-By: Oz oz-agent@warp.dev