MoonshotAI / MoonshotAI/kimi-code

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

Open
#2,736 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
7.5k
Forks
1.2k
Avg merge
11h 53m
Merged PRs (30d)
350

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the TUI session-resume path behind kimi -S <id>/--continue and the existing local server/ACP plumbing used by kimi web. Done means a second terminal can attach to the running session, share its live transcript and input, and prevent independent agent loops from racing on the session store.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
api, cli, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.