[RFC] Agents view: one screen to manage all sessions (kimi agents)

[ysyneu]

The problem

Using Kimi Code today means one window, one session:

• To run several agents in parallel you open a pile of terminal windows. Once you have a few, nobody knows which one finished, which one is waiting for a permission approval, and which one is stuck — you Alt-Tab through all of them and keep the state in your head
• Sessions can't see each other. A long task is grinding in window A, and you can't check on it from window B
• Want to continue a session somewhere else? Close it and start over

Claude Code already answered this with its agents view (claude agents): one screen that lists all your sessions, lets you jump into any of them, dispatch new work, and see at a glance who is waiting for you. We tried it hands-on and mapped every interaction — this is exactly the piece Kimi Code is missing.

The proposal: kimi agents

A new kimi agents command that opens a full-screen console:

• The list: one row per session — title, latest progress, status (running / waiting for you / done), and age
• Enter to jump in: the full chat UI for that session; press ← to come back, and the session keeps running in the background, uninterrupted
• A dispatch box at the bottom: type a task to spawn a new session, with command suggestions (e.g. picking a model) — no new window needed
• Space to peek: expand a session's latest output without leaving the list, and reply right there to steer it
• Management keys: Ctrl+X to delete (press twice to confirm), Ctrl+R to rename, Ctrl+T to pin

What it looks like (sketch):

flowchart TB
    H["Header: 2 running · 1 waiting for you · 5 done"]
    L["Session list:<br/>▶ Waiting for you — title + latest progress + age<br/>▶ Running — same, with a spinner<br/>▶ Done — same, long lists collapse"]
    P["Peek panel (Space toggles): latest output + reply right there"]
    I["Dispatch box: › describe a task for a new session…"]
    F["Footer: enter to open · space to peek · ctrl+x to delete · ? for shortcuts"]
    H --> L --> P --> I --> F

Loading

Why this makes you faster

1. Parallel work without a window farm. Dispatch, watch progress, collect results — all on one screen. Today, 5 tasks means checking 5 windows in rotation; with the list, one glance tells you who needs you
2. "Waiting for you" stops piling up. Agents pausing for a permission approval is routine, and a window buried in the background is easily forgotten for half an hour. Now they form their own group at the top of the list — and while you're attached to another session, the footer still reminds you
3. Switch in a second, nothing is interrupted. Watching agent A work, jump to B to approve something, jump back — A kept running the whole time. Like switching browser tabs
4. It connects with the web UI. Sessions created in kimi web show up in the same list — the terminal and the browser stop being two separate worlds

How we'd build it (plain words)

Kimi Code already has a hub: the server process behind kimi web (kap-server). Its talent is hosting many sessions at once — sessions live inside the hub, and any client that connects can see them: the web UI connects to it, the kimi-inspect debug tool connects to it.

So this feature is really just: build a terminal console on top of the hub. The sessions themselves, their persistence, and multi-session concurrency are all things the hub already does today; the API surface (list sessions, send prompts, answer approvals, read transcripts) is essentially complete. What's missing is mainly two pieces:

1. A wire layer that lets the terminal UI talk to the hub (the repo already has a test client we can productize as the starting point)
2. The console UI itself (reusing the existing terminal UI components)

flowchart LR
    A["kimi agents<br/>(the new console)"] -->|"connects (same machine)"| B["kap-server hub<br/>hosts many sessions"]
    C["kimi web (browser UI)"] --> B
    D["kimi-inspect (debug tool)"] --> B
    B --> E["session 1 (running)"]
    B --> F["session 2 (waiting for you)"]
    B --> G["session 3 (done)"]

Loading

The daemon question — we thought it through

We know and respect the history: 0.28.0 deliberately removed the background-daemon model (#1826, #1967) and set the rule "a process stays alive = a human is watching a terminal". The reasons it was removed (zombie processes, version drift, support burden) are real, and we agree with them.

So the first red line of this design: never leave a sneaky background process behind. Concretely:

flowchart TD
    Start["kimi agents starts"] --> Q{"is a hub already running?<br/>(e.g. you have kimi web open)"}
    Q -->|"yes"| Join["just attach to it"]
    Q -->|"no"| Embed["embed a hub inside the view's own process"]
    Join --> Use["use it"]
    Embed --> Use
    Use --> Exit{"when you quit the view"}
    Exit -->|"attached to someone else's hub"| Keep["disconnect only —<br/>every session keeps running"]
    Exit -->|"using the built-in hub"| Ask{"any sessions still running?"}
    Ask -->|"yes"| Confirm["confirm dialog:<br/>these sessions will be interrupted, everything is saved"]
    Ask -->|"no"| Bye["clean exit"]
    Confirm --> Bye

Loading

In two sentences:

• Attach to a running hub if there is one; otherwise carry our own, and our own hub lives and dies with the view — every process always has someone watching it. The rule holds, untouched
• An interrupted session loses nothing: the transcript is on disk, the next launch brings it back exactly as it was, and a short "continue" gets it going again. Users who want "close the window and the task keeps running" simply keep a kimi web terminal open — the choice to stay resident belongs to the user, the tool never makes it for them

Known trade-offs (the honest list)

• Console sessions run on the v2 engine (the hub only speaks v2); resuming them later via plain kimi --resume (v1) may not work — entering them from the console is always fine
• Inside an attached session, two small things are temporarily absent: the plugin command panel is empty, and one-shot ! shell commands are unavailable (the hub has no routes for these yet; they can be added later)
• Foreground kimi sessions in other terminal windows do not appear in the list (they are not hosted by the hub)
• Same machine only (the console and the hub run on the same host)

Three questions for the maintainers

1. Is the overall direction OK? Per the repo rules, we came here first — no PR until you've had a chance to respond
2. Should the console offer a one-click "trust this directory" action? (The route exists, but this is a security-policy decision — our default is no, and we'll take your lead)
3. If the direction is approved, we'd like to contribute the full implementation: we have a detailed design and code-level investigation against latest main (including feat(agent-core-v2): introduce the Workspace domain and the agent-profile registry extension point #2366), and can structure the work into clean milestones — wire layer → lifecycle → list UI → attach — or split PRs however you prefer

---

Additional notes. This is not the same ask as #2131: that issue wants a panel for subagents inside one session; we propose a console across sessions. The two don't conflict — our list could later host #2131's attach view. We're also aware of the stalled PR #1139 (a read-only /agents status command); this proposal is a superset, and if accepted we're happy to cover or close it as part of the work.