feat: multi-session support — server API, web UI tabs and TUI tabs

The work spans multiple subsystems: kap-server API changes (packages/kap-server), TUI session management (apps/kimi-code/src/tui/kimi-tui.ts), and reverse-RPC controllers. Start by reviewing the existing session lifecycle in KimiTui.setSession and the agent-core-v2 scope model. Understand how the web UI already handles multiple sessions via kap-server. 'Done' means a single TUI instance can host multiple concurrent sessions, switch between them without interruption, and preserve per-tab state, likely behind a feature flag.

What feature would you like to see?

Multi-session support inside a single TUI instance: keep several sessions alive at once and switch between them without interrupting any of them.

Current behavior

Today the TUI is strictly one process = one live session:

• /sessions (/resume) and /new replace the current session. KimiTui.setSession unloads the previous session and calls previous.close() before attaching the new one (apps/kimi-code/src/tui/kimi-tui.ts, setSession). If a long task is still running, switching away interrupts it.
• The only way to work on two things in parallel is to open more terminal windows/tabs, each with its own kimi process. Once you have three or four of them you lose track of which one finished, which one is waiting for a permission approval, and which one is idle.
• Context is lost on every hop: pending approvals, the partially typed prompt, scroll position, attached images and the task list all belong to the process, not to the session you are looking at.

Proposal

Let one TUI instance host multiple concurrent sessions and expose them as tabs:

• /new --tab (or Ctrl+T) opens a new session in a new tab; /sessions gets a "open in new tab" action next to "resume here".
• Ctrl+Tab / Ctrl+Shift+Tab (or /tab 1..9, Alt+1..9) switch tabs. Switching never closes the session it leaves; the agent keeps running in the background.
• A compact tab strip (or a segment in the status line) shows each session's title and state: ● running, ⏸ waiting for you (permission/AskUserQuestion pending), ✓ done, ! error, with an unread marker when a background tab produced output since you last looked.
• Per-tab state is preserved: draft input, scroll position, pending approvals, staged attachments.
• /tab close (Ctrl+W) closes a tab with a confirmation if the session is still running; closing the last tab behaves exactly like today.
• Background sessions can raise the same terminal notification hooks that the foreground one does when they finish or need input.

Why this is worth it (user-facing benefits)

1. Far more user-friendly than a window farm. Parallel work becomes "switch tab" instead of "find the right terminal window". Everything about a workspace lives in one place, which is what people already expect from editors and browsers.
2. No accidental interruptions. Switching sessions today silently kills the previous one's in-flight work. With tabs, a switch is a view change, not a lifecycle event, so a 20-minute refactor in tab 1 is never lost because you wanted to ask a quick question in tab 2.
3. "Waiting for you" stops being invisible. Permission prompts and questions from background sessions surface as a badge on the tab strip, so approvals do not sit forgotten in a buried window for half an hour.
4. Cheaper on resources. One process, one plugin/MCP/server initialisation, one set of file watchers and one auth/telemetry context instead of N copies. Startup cost is paid once per workspace rather than once per task.
5. Natural fit for common workflows. Review PR A while B implements a feature; keep a "scratch" tab for questions about the codebase next to a long-running plan-mode tab; run /fork into a new tab to try a different model and compare results side by side (complements #3389).
6. Smoother path to the rest of the roadmap. #2444 (kimi agents console) proposes a separate full-screen manager on top of the kap-server hub. Tabs are the lightweight, in-TUI counterpart: same underlying multi-session hosting, but zero context switch for the everyday case of 2–4 sessions. #2939 (cross-session messaging) becomes much more discoverable when the peer sessions are visible tabs in the same window.

Rough implementation notes

• The engine side already supports many live sessions per process: agent-core-v2 scopes are App / Workspace / Session / Agent, and kap-server hosts many sessions concurrently for the web UI. The gap is purely in the TUI, which keeps a single this.session and a single set of session handlers.
• KimiTui would hold a Map<sessionId, TabState> (session handle, transcript view state, draft, pending approvals) and route registerSessionHandlers events to the owning tab instead of the global state; only the active tab renders.
• setSession becomes "activate tab" and no longer closes the previous session; close() moves to an explicit tab-close action.
• Reverse-RPC controllers that assume one session (permission prompts, AskUserQuestion, plan approval) need a sessionId on their pending requests so a background tab's prompt is queued for that tab rather than shown over the active one.
• Could ship behind KIMI_CODE_EXPERIMENTAL_TUI_TABS first.

Additional information

Related: #2444 (Agents view / kimi agents), #2939 (cross-session messaging), #3389 (/fork-session), #3954 (sidebar session ordering on Desktop). None of them cover switching between live sessions inside the existing TUI without closing them.

Happy to help refine the UX (keybindings, tab strip layout) if the team is interested.

Delivery plan (split into PRs)

The engine already hosts many live sessions per process, but three layers need work before "keep several sessions alive and switch between them" is usable from any client. Tracking them as separate PRs so each stays reviewable:

• PR 1 — kap-server API (packages/kap-server, this repo) — #3986
  • WebSocket subscribe / subscribe_v2 / client_hello resume a cold session on demand (ack reports resumed / failed).
  • Broadcaster drops per-session state when the engine closes/archives a session, so a re-resumed session streams events again.
  • POST /api/v1/sessions/resume (batch) and GET /api/v1/sessions/live (loaded sessions with busy / idle / subscriber info).
  • [server] max_live_sessions (default 16) and [server] session_idle_timeout_ms (default 30 min): idle sessions are closed, busy ones never; subscribers get a global event.session.closed and can re-subscribe.
  • GET /api/v1/meta → capabilities.multi_session for feature detection.
• PR 2 — web UI tabs (code-app apps/web): detect capabilities.multi_session, subscribe to several sessions over one socket, show background-session state, re-subscribe on event.session.closed. Left to the maintainers: the web UI source lives in the private code-app repo, so external contributors cannot open this PR. The server contract it needs is fully described in #3986.
• PR 3 — dist-web bundle sync (this repo, mechanical pnpm run sync:web after PR 2 lands; also maintainer-only for the same reason).
• PR 4 — TUI tabs (apps/kimi-code), as described above; can reuse the same session-hosting policy. — #3988