Skip to content

Revert: let idle desktop chat views beyond the three most recent go - #2473

Merged
AbirAbbas merged 2 commits into
app/v3from
revert/2472-view-holds
Nov 6, 2026
Merged

AbirAbbas merged 2 commits into
app/v3from
revert/2472-view-holds

Conversation

@AbirAbbas

Copy link
Copy Markdown
Collaborator

Reverts #2472. That change reopened #2471.

Why

#2472 let the idle sweep release an open desktop view once it is outside the 3 most recently used. A regression check found that this lets another process run a turn in a chat the window is still showing. The window then misses that turn's content.

Measured with a standalone codeaf app (app/v3 2c717c0) on a scratch home, driven over its wire:

  • Setup: 5 chats created and opened. After the idle sweep, the 2 oldest were released and the 3 most recent stayed held, as designed.
  • Turn from the CLI: codeaf chat --once --session <released chat> on the same home ran (exit 0). Before Let idle desktop chat views beyond the three most recent go #2472 the same command is refused with "this conversation is open in another window". The control run against a still-held chat on the same binary refused it in exactly that way.
  • What the window got: for that outside turn, the app engine emitted only agent.changed working → idle. It sent no turn.* and no entry.added, and updated_at did not move. The CLI process holds no engine host, so the app cannot join it, and the window shows nothing of the turn until it re-reads.
  • Sending afterwards: a send from the app into that chat worked (turn.done ok:true). On reopening the chat, though, the app then started an extra turn on its own: "The app closed unexpectedly while you were in the middle of answering…".
  • Same-engine sources are not affected: a second window of the same app and in-engine factory runs reopen the chat in the app engine and stream normally.

Rather than ship that, this restores the held view until #2471 has a fix that bounds the per-chat files and keeps the refusal. Possible directions:

  • a desk "view closed" call, so the engine knows when a chat is no longer shown;
  • keeping the hold but shedding the presence watch's per-file kqueue handles on macOS, which are 6 of about 7 fds per chat.

Change

git revert of 2c717c0, plus a change entry. The code, test and manual return to their state before #2472.

🤖 Generated with Claude Code

AbirAbbas and others added 2 commits November 6, 2026 13:56
…2472)"

This reverts commit 2c717c0.

Releasing an open view lets another process (the codeaf CLI on the same home)
run a turn in a chat the window is showing. Before #2472 that turn was refused
("this conversation is open in another window"). After it, the turn runs, the
window gets only working/idle state for it and none of its entries, and the
app's next open of that chat starts a spurious "the app closed unexpectedly"
resume turn. Restore the held view until a fix keeps both.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@AbirAbbas
AbirAbbas merged commit 34c832e into app/v3 Nov 6, 2026
6 checks passed
@AbirAbbas
AbirAbbas deleted the revert/2472-view-holds branch November 6, 2026 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant