TUI keeps serving a stale in-memory transcript after external turns are appended to the session wire file — continuing to type forks the conversation

Environment

• kimi-code CLI (production), macOS (mac mini, Apple Silicon)
• Session hosted in a running TUI; a second client (mobile, via ACP attach) injects turns into the same session
• Session store: ~/.kimi-code/sessions/.../agents/main/wire.jsonl

What happened

With a kimi TUI session open and running, we attached a mobile client and exchanged messages. The mobile-originated turns were executed and fully persisted to the session's wire.jsonl (user questions, assistant replies, turn.ended events all present). The running TUI, however:

1. never displayed the externally-added turns (live view is pure in-memory state);
2. re-selecting the same (current) session via /sessions showed none of them — only a fresh process resume (kimi -S <id>) revealed the full history;
3. critically, continuing to type in the stale TUI forks the conversation: in a numbered probe (TUI side told "remember 1/2/3", mobile side told "remember 4/5/6"), the original TUI afterwards knew only 1/2/3 and nothing of 4/5/6 — two divergent histories now interleave in one session file.

Expected

One of:

• Hot reload: the TUI watches the wire file for external appends and merges them into the live view/context; or
• Guard: the TUI detects external modification and refuses further input with a clear prompt (e.g. "session changed externally — resume with kimi -S <id> to continue"), making the fork impossible.

Actual

Silent staleness. Nothing in the UI hints the session moved on elsewhere; the user resumes typing and unknowingly forks the transcript. The model's own answers cannot be trusted to detect this either (it may deny having seen messages that are in its context, or vice versa) — the fork is only visible at the wire-file level.

Why this matters

Cross-device continuation is a core workflow: start at the desk, continue from the phone, come back and pick up at the desk. Today the "come back" step requires knowing an undocumented rule — abandon the running TUI and resume in a fresh process. Users who don't know the rule silently corrupt their session history. A file-watch or a guard prompt is a small, contained change on the TUI side; the persistence layer already records everything needed to detect the condition (compare in-memory tip vs. wire file tail before accepting input).

Start by tracing the TUI's session selection and input-handling paths, then inspect how the active transcript relates to the session's agents/main/wire.jsonl file. Reproduce the external-append scenario with a second client and verify either that appended turns appear in the live context or that further input is blocked with a clear resume instruction.