Repository navigation
🤖 Composer: Edit in one window also loads the message into another window's composer #5571
Description
Activity
Picked up by the issue coordinator: workspace workspace-68, branch fix/5571-edit-window-local
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high• Cost:$Triage: B (multi-window design needed). Reproduced on main
eea905df90.Repro (dev server, mock model, two browser clients on one workspace):
- Window A sends "first message to edit".
- Window B opens the same workspace. Its composer is empty.
- Window A clicks Edit. A shows "Edit your last message" with the text.
- Window B's normal composer ("Message Claude", not in edit mode) now also holds "first message to edit". If B presses Send, the message goes out a second time.
- Window A presses Escape. Both composers are empty again.
Cause: edit mode is per-window React state (
ChatPaneeditingState), but entering edit writes the message into the composer's draft (ChatInputapplyDraftFromPending), and the draft is the backend-shared{kind: "workspace"}scope. DraftStore pushes it to every window. The pre-edit draft lives only in window A's memory (editSessionRef.preEditDraft), so a reload during edit also loses it.Why B: a fix must decide where edit text lives. Proposed design: while editing, the composer edits a memory-only per-window scope (DraftStore already has memory-only scopes), and the shared workspace draft stays untouched. That removes the pre-edit snapshot/restore, keeps other windows' drafts, and changes one behavior: edit text no longer survives a reload. It touches the edit session, send settle and restore paths in
ChatInput, so it is not a small single-path fix.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high• Cost:$Decision: backlog until the maintainer picks the product tradeoff. User-visible risk today: after Edit in window A, Send in window B sends the message a second time, and Escape in window A also empties window B's composer (B's own draft text is replaced while A edits). The proposed fix (a memory-only per-window edit scope) means edit text no longer survives a reload.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high• Cost:$2.57Maintainer decision (2026-10-04): this stays in the backlog. The repro and risk are recorded above:
- Clicking Edit in window A also loads the message into window B's composer.
- Send in window B then duplicates the message.
- Escape in window A empties both composers.
The proposed fix keeps a per-window edit scope in memory only. It trades away edit text surviving a reload, so it's deferred. Trigger: a user report, or other work on how composer drafts sync across windows.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high- added a commit that references this issue
on Oct 5, 2026 - added 6 commits that reference this issue
on Oct 6, 2026 Status: this issue stays open. #5893 closed unmerged (#5893 (comment)). #5801 stays a parked draft. The same work covers this issue and #5672.
- Owner: the coordinator desk.
- Re-plan trigger: a user report of draft loss during an edit, or a design that is materially simpler than S1 below.
S1 trade-offs, for the next planner:
- S1: the composer's edit buffer is the only owner of the edit's text and files until the backend accepts the edit. The edit never enters the shared draft, so other windows never see it.
- Cost to users: the edit stays read-only while its send runs. A switch during an edit send that the backend then accepts leaves a visible duplicate in the draft.
- It still needs a busy gate, a decision when the target disappears during the send, and one merge for a queued-card race.
- Estimate: about +185/−60 production lines, against 🤖 fix: keep an open edit out of the shared draft #5893's +244/−55. Not materially simpler, so we stopped.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high• Cost:$173.34
Summary
Reported during PR #5547 dogfooding, not yet verified independently: when a user clicks Edit on a sent message in one window, the edited message also appears in the composer of a second window that shows the same workspace.
The worker who reported it says
origin/mainbehaved the same before #5547, so this is not a regression from the send-ID work.Expected
Only the window where the user clicked Edit enters edit mode and shows the message in its composer.
Next step
Reproduce with two windows (dev-server sandbox + agent-browser) on current main, then decide whether edit state is per-window UI state or shared draft state. Related: #5547, #5567, #5557.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high