MoonshotAI / MoonshotAI/kimi-code
[Web] User message missing from live session transcript after switching away and back (fork renders it; wire log intact)
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
- In the web UI, run a session with a long-running turn (in my case a 16-subagent swarm, if relevant).
- Send a follow-up prompt (long text, ~1000 chars). The agent starts working.
- While the agent runs, switch to another session in the sidebar.
- 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— promptIdmsg_01M1VHB8YKSMTF5N4JN04X4DED, time 1788704302051turn.prompt— same id, time 1788704303238context.append_message— role"user", same id
Possibly relevant details
- This was the first prompt in that session that carried a
UserPromptSubmithook attachment (ahook_resultblock injected by a hook inconfig.toml: codebase-memory-mcp'shook-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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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