**Environment**
- App: Kimi Desktop (Kimi Work) **3.2.10**, release, packaged
- OS: Windows 10.0.26200 (win32, x64)
- Runtime: Electron 43.6.0, Node 24.20.0, Chrome 150.0.7871.250
- Agent kernel: kimi-code (as bundled with the desktop app)
## Summary
A conversation turn that **completes successfully on the server side** is never rendered in the desktop client. The chat window stays on the “thinking” spinner indefinitely; the last visible assistant message shows a stale status line (“Tools used: 11 · commands executed: 2”). Meanwhile:
- The completion **notification arrives** (via an external channel configured by the user).
- Opening the **same conversation from a second machine / remote session** shows the turn fully completed, with all final messages and results.
- The conversation state on disk (`conversations.sqlite`, transcripts) is complete and consistent.
So the data is fine — the local renderer never receives/renders the final turn state. The window looks hung, but the session itself has finished.
## Steps to Reproduce
1. Start a long-running agent task in Kimi Work desktop on Windows. In my case the turn included **detached long-running shell commands** (a background Gradle test run launched via `Start-Process`, then polling its log with repeated `sleep 280` shell calls — i.e. single tool calls that block for up to ~5 minutes each with no streamed output).
2. Wait for the task to finish (confirmed externally: notification received, MR created).
3. Observe the chat window: spinner still animating, no new messages, “tools used” counter stale. Waited 15+ minutes — no update.
4. (Optional) Open the same conversation from another client/session — the completed turn with all final messages is there.
## Expected Behavior
When a turn finishes — including turns that finish while the client’s connection was interrupted or idle — the client should sync the final turn state and render the result, not keep the spinner. Cf. kimi-code changelog 0.23.6 (2026-07-12): *“Fix sessions getting stuck in a sending state after a reconnect; turns that finish while the connection is down now stop the spinner.”*
## Actual Behavior
The desktop client never catches up. Restarting the app was required to force a re-sync of the conversation state (after restart the completed turn renders correctly).
## Evidence
- Screenshots: chat stuck on spinner with stale “tools used: 11” line; second screenshot ~10 min later — identical, still spinning.
- `diagnostics/session-history.json` confirms app version 3.2.10 and a healthy app session (no crash, app itself is responsive — other UI works; only the conversation view is stale).
- The turn’s transcript exists in `daimon-share/…/memory/transcripts/` — the agent finished; the desktop renderer did not pick it up.
- No “Connection lost” banner was shown at any point — the staleness is silent.
## Possibly Related Known Issues (kimi-code changelog)
- 0.23.6 (2026-07-12): sessions stuck in a sending state after reconnect; turns finishing while connection is down now stop the spinner.
- 0.23.2 (2026-07-08): recover chat streaming after a stale background-tab WebSocket.
- 0.24.0 (2026-07-14): session rendering glitches when reopening / reconnecting / resyncing.
- 0.25.0 (2026-07-16): completed background subagents losing their final output after a session reload.
These fixes appear to cover the web UI of the kernel; the desktop shell (3.2.10) seems to still exhibit the stale-renderer behavior, possibly via its own sync path between the Electron client and the local daimon runtime.
## Suspected Trigger
Turns containing **very long-running individual tool calls** (minutes of silence — detached processes polled with long sleeps) seem to coincide with the client missing the turn-completion event. Possibly a WebSocket/event-stream timeout or reconnect path that drops the terminal “turn finished” event without a full state re-sync.
**Update (same day, second occurrence):** the same staleness reproduced in a different, unrelated conversation with no long-running tool calls at all — ordinary short Q&A turns. This suggests the long silent tool calls are not a required trigger; the renderer can miss turn completion in routine use as well. In both cases the fix was the same: fully restart the desktop app, after which the completed turns render correctly from the persisted session state.
**Update 2 — the client is not fully disconnected:** while the conversation view is stale, the **control channel still works in real time**. While driving the same session from a second (remote) client, tool approval prompts still arrive at the stale desktop client and function normally — approving them on the stale screen affects the live turn. Only the conversation transcript/stream updates are stuck; permission/approval events keep flowing. This points to a desync in the conversation-state sync path specifically, not a dead connection or a wholly frozen renderer.