MoonshotAI / MoonshotAI/kimi-code

[Web] User message missing from live session transcript after switching away and back (fork renders it; wire log intact)

Open
#3,583 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

In the Kimi Code CLI's web view (the experimental remote-control feature that serves the CLI session in a browser), after switching to another session while the agent was running and switching back once the turn had completed, one user prompt bubble is missing from the transcript. The message is fully persisted in the local wire log, and a forked copy of the same session renders it correctly — so this is a rendering / state-sync bug in the live web view, not data loss.

kimi Code CLI 的 web 功能(experimental remote-control,在浏览器里查看/操作 CLI 会话)中:agent 运行期间切到其他会话、轮次完成后切回来,该轮用户消息的气泡从记录里消失(截图 1);本地 wire 日志数据完整,fork 出的会话能正常显示同一条消息(截图 2)——是实时会话视图的渲染/状态同步问题,不是丢数据。

Environment

  • kimi CLI 0.41.0
  • WSL2 (Linux 6.18.33.2-microsoft-standard-WSL2, x86_64)
  • Web UI via experimental remote-control = true
  • Session id: 2e7040a1-6237-4d07-8742-882fad3b4677

Steps to reproduce

  1. In the web UI, run a session with a long-running turn (in my case a 16-subagent swarm, if relevant).
  2. Send a follow-up prompt (long text, ~1000 chars). The agent starts working.
  3. While the agent runs, switch to another session in the sidebar.
  4. After the turn completes, switch back to the first session.

Expected

All user messages render in order.

Actual

The prompt from step 2 has no bubble in the live transcript; the view jumps from the previous assistant message straight to the new turn's diff card / thinking / reply (screenshot 1). Forking the session produces a transcript where the same message renders correctly with its timestamp (screenshot 2).

Evidence that persistence is fine

The session's local agents/main/wire.jsonl records the message in all three expected events with origin.kind = "user":

  • prompt.accepted — promptId msg_01M1VHB8YKSMTF5N4JN04X4DED, time 1788704302051
  • turn.prompt — same id, time 1788704303238
  • context.append_message — role "user", same id

Possibly relevant details

  • This was the first prompt in that session that carried a UserPromptSubmit hook attachment (a hook_result block injected by a hook in config.toml: codebase-memory-mcp's hook-augment --dialect kimi). The previous prompt (sent before the hook existed) renders fine. Causation is unconfirmed — the forked copy renders the message — but it is the main distinguishing feature of the swallowed message.
  • TUI-side relative: #2835 (stale in-memory transcript vs. session wire file). This looks like the web counterpart: the live view's state desyncs from the persisted wire log when reattaching to a completed turn.

Workaround

Fork the session — the fork's transcript is complete.

screenshot-1-live-view screenshot-2-fork

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 reproducing the issue in the experimental remote-control web view, switching sessions during a running turn and returning after completion. Inspect the live transcript reattachment and state-sync path, comparing its events with agents/main/wire.jsonl and the forked session. Done means the step-2 user prompt renders in order after switching back.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend, web-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.