[Bug]: Switching device surface can leave a completed turn stuck in "receiving parameters"
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
Research direction
Start by tracing the Agentic event listener registration around the local/peer surface switch and the settled-turn snapshot reconciliation path. Compare the in-memory tool-card projection with the persisted turn state described in the report. Done means switching back or receiving a settled snapshot clears any streaming/preparing tool card when the authoritative turn and tool calls are complete; verify with the reproduction sequence.
Written by the indexing model from the issue text.
Description
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
Edittool card remains stuck atreceiving 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:
- Start a long-running local turn containing several tool calls, including an
Edittool. - While an Edit card is still receiving/streaming its arguments, manually switch control to a peer device surface.
- Allow the original host to finish the turn.
- Switch control back to the local device and reopen the session.
- 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 switchedfrom local (null) to a peer device (reason: manual).09:34:18: the host received the final response, completed the turn loop withreason=complete, emittedDialogTurnCompleted, cleaned the cancellation token, and transitioned the backend session toIdle.10:43:53: the surface switched back from the peer device to local.- Subsequent snapshot reconciliation reported backend state
Idleand the correct latest turn ID, but the old Edit card remained visually stuck inreceiving 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)
- Dominant language
- Rust
- Stars
- 2.3k
- Forks
- 236
- Avg merge
- 2h 56m
- Merged PRs (30d)
- 619
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.
More from GCWing/OpenBitFun
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
GCWing/OpenBitFun#3213 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
GCWing/OpenBitFun#2363 ·
-
question
Difficulty 1/5 Under an hour Newbie friendliness 78/100
GCWing/OpenBitFun#2340 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
GCWing/OpenBitFun#3210 ·
-
GCWing/OpenBitFun#3195 · 2 comments · 1 assignee ·
All issues in GCWing/OpenBitFun
Similar issues
-
bug CLI custom-model
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
rust-bitcoin/rust-bitcoin#6930 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
fulcrumgenomics/ferro-hgvs#2251 ·
-
A-allocators A-docs C-enhancement T-libs
Difficulty 2/5 1-3 hours Newbie friendliness 75/100