What happened
A temporary Side Chat opened from the right Workbar is lost when the user switches to another main session and then returns to the source session.
This is most visible when the user sends the Side Chat's first request and navigates away while its temporary fork is still being created or its turn is running. The Side Chat panel disappears instead of remaining associated with its source session. In some runs, the temporary fork briefly flashes in the left task rail before disappearing.
Expected behavior:
- Switching main sessions should hide, not close, Side Chats owned by the previous session.
- Returning to the source session should restore the same Side Chat transcript and any in-flight turn.
- The temporary fork should remain hidden from the main task rail.
- Only explicitly closing the Side Chat should stop and delete its temporary fork.
How to reproduce
- Create two ordinary main sessions, A and B.
- Open session A.
- Expand the right Workbar and open Side Chat.
- Enter the first Side Chat request and press Enter.
- Immediately switch to main session B while the Side Chat request is starting or still running.
- Switch back to session A.
Actual result: the Side Chat opened in step 3 is gone. The temporary fork may briefly appear in the left task rail before it is removed.
Environment
- Maka commit:
672d82731a63
- OS: macOS 15.6 (
24G84)
- Surface: Desktop
- Node.js:
v24.19.0
Logs, screenshots, or additional context
The Workbar controller currently treats Side Chat panels whose sourceSessionId differs from the newly active main session as stale. It closes their tabs and removes their records. Unmounting the panel then runs the ephemeral-fork dismissal path, so ordinary navigation becomes destructive.
There is a second ordering race in the task rail: the Host broadcasts the newly created fork before the renderer receives its ID and adds it to the local hidden-ID set. Filtering the durable mode:side_conversation label at rail projection time avoids the one-frame flash.
Acceptance coverage should switch away immediately after the first Side Chat send starts, verify the fork still exists while another main session is active, return to the source session, and verify that explicit close remains the deletion boundary.
Prepared with substantive assistance from Maka; the human reporter reviewed and owns this report.
What happened
A temporary Side Chat opened from the right Workbar is lost when the user switches to another main session and then returns to the source session.
This is most visible when the user sends the Side Chat's first request and navigates away while its temporary fork is still being created or its turn is running. The Side Chat panel disappears instead of remaining associated with its source session. In some runs, the temporary fork briefly flashes in the left task rail before disappearing.
Expected behavior:
How to reproduce
Actual result: the Side Chat opened in step 3 is gone. The temporary fork may briefly appear in the left task rail before it is removed.
Environment
672d82731a6324G84)v24.19.0Logs, screenshots, or additional context
The Workbar controller currently treats Side Chat panels whose
sourceSessionIddiffers from the newly active main session as stale. It closes their tabs and removes their records. Unmounting the panel then runs the ephemeral-fork dismissal path, so ordinary navigation becomes destructive.There is a second ordering race in the task rail: the Host broadcasts the newly created fork before the renderer receives its ID and adds it to the local hidden-ID set. Filtering the durable
mode:side_conversationlabel at rail projection time avoids the one-frame flash.Acceptance coverage should switch away immediately after the first Side Chat send starts, verify the fork still exists while another main session is active, return to the source session, and verify that explicit close remains the deletion boundary.
Prepared with substantive assistance from Maka; the human reporter reviewed and owns this report.