[Bug]: Switching device surface can leave a completed turn stuck in "receiving parameters"

Inizia tracciando la registrazione dell’Agentic event listener intorno al local/peer surface switch e al settled-turn snapshot reconciliation path. Confronta la in-memory tool-card projection con il persisted turn state descritto nel report. Il lavoro è completato quando il ritorno indietro o la ricezione di un settled snapshot cancella qualsiasi streaming/preparing tool card una volta completati l’authoritative turn e le tool calls; verifica con la reproduction sequence.

Summary

Switching the active device surface while a turn is running can leave the original desktop UI with contradictory state after the host finishes:

• the session/sidebar indicates that the turn completed;
• the persisted turn and backend state are terminal (completed / Idle);
• an earlier Edit tool card remains stuck at receiving parameters;
• there is no effective Stop action because the backend has already removed the cancellation token.

This appears to be a device-surface event projection/reconciliation issue rather than a runtime deadlock. The settled persisted turn does not fully replace the stale in-memory tool-card projection after returning to the local surface.

Expected: After switching back, or after receiving a settled-turn snapshot, the UI should reconcile every tool item to the host's authoritative persisted state. A completed turn should not retain a streaming/preparing card.

Actual: The sidebar and session metadata show completion while one tool card continues to look active indefinitely. Restarting the desktop app restores a consistent view.

Area

Desktop app / Web UI (peer device surface switching and settled-turn reconciliation)

Reproduction or evidence

A likely reproduction sequence is:

1. Start a long-running local turn containing several tool calls, including an Edit tool.
2. While an Edit card is still receiving/streaming its arguments, manually switch control to a peer device surface.
3. Allow the original host to finish the turn.
4. Switch control back to the local device and reopen the session.
5. Observe that the session is marked complete but the earlier Edit card still says receiving parameters, with no meaningful way to stop it.

Evidence from one occurrence (timestamps are local):

• 09:32:40: the local window became visible and the same turn was attached/projected.
• 09:32:45: the Agentic event listener was stopped and then registered again.
• 09:32:46: Device surface switched from local (null) to a peer device (reason: manual).
• 09:34:18: the host received the final response, completed the turn loop with reason=complete, emitted DialogTurnCompleted, cleaned the cancellation token, and transitioned the backend session to Idle.
• 10:43:53: the surface switched back from the peer device to local.
• Subsequent snapshot reconciliation reported backend state Idle and the correct latest turn ID, but the old Edit card remained visually stuck in receiving parameters.

Persisted data for the affected turn confirms:

• turn status: completed;
• finish reason: complete;
• hasFinalResponse: true;
• all 19 model rounds are completed;
• all 21 tool calls are completed;
• the exact Edit tool shown as streaming in the UI has a persisted successful result.

A process sample taken while the UI was stuck showed the normal AppKit/CoreFoundation event loop and no mutex/thread deadlock. There were no child tool processes still running.

There were also repeated get_operation_diff: Session not found / get_operation_summary: Operation not found warnings for file-operation cards that modified a file outside the active workspace. These may make the stale card more visible, but the host turn itself completed successfully and they may be a separate degradation issue.

Environment, if relevant

• OpenBitFun: 1.0.0
• Build commit: a0d6a6fe53e0d86fa81d61390cf6f661e8a55307
• Build date: 2026-09-15T09:04:07.335Z
• OS: macOS 27.0 (26A428)
• App mode: native desktop app, local workspace with peer device surface switching
• Model shown in the affected session: GLM 5.3 (the issue appears independent of provider/model)