Feature request: attach two terminals to the same live session simultaneously

[myagizmaktav]

Summary

There is currently no way to attach a second terminal to an already-running Kimi Code session. kimi -S <id> / --continue loads the session history into a new, independent process — so two terminals pointed at the same session each run their own agent loop and diverge (or race on the session store), instead of sharing one live session.

Use case

• Start a long-running session in one terminal, then attach from a second terminal (another pane, another machine over SSH, or desktop + laptop) to watch progress or steer the agent.
• Comparable to tmux attach for shells, or running the same agent session from both the TUI and kimi web at once.

Current behavior (v0.34.0)

• Resuming a session from two terminals spawns two independent processes with the same history; turns are not synchronized, and both processes write to the same session files.
• kimi web / ACP expose sessions over a server, but the terminal TUI cannot join an already-running session as a second client.

Proposal

An attach mode for the TUI, e.g. kimi attach <session-id> (or kimi -S <id> --attach):

• The second terminal connects to the running session's process (via the existing local server / ACP plumbing) instead of forking a new agent loop.
• Both terminals see the same live transcript and can submit input; one agent loop, multiple views.
• A session lock or explicit multi-client flag would prevent the current silent divergence when two processes resume the same session.

Alternatives considered

• kimi web — requires a browser; doesn't help terminal-only workflows (SSH, tmux).
• tmux/screen sharing — shares keystrokes of one TUI instance, not a real second client; resize and scroll behave poorly.

Environment

• kimi-code 0.34.0, Linux x86_64