Describe the bug
Edits made in the editor while the AI agent is running are silently lost when the agent's turn finishes.
The chat sends a full document snapshot taken at Send time, the agent folds its edits onto that snapshot in the main process, and the renderer applies the returned document wholesale — setDocument + saveDocument — with no check that the live document has moved in the meantime. Last write wins on a stale base, so every user edit made during the turn (padding, background, a trim, a zoom, a clip move, a title change…) is overwritten on screen and on disk.
Where it happens:
Note this is not the torn-file race DocumentService.writeProject already guards against (that queue makes the two saves sequential and atomic — it just means the agent's stale document is written cleanly on top of the user's).
The one mitigation today is that setDocument pushes the previous document onto the undo stack, so a single Ctrl+Z restores the user's version — but it then throws away the agent's work, and nothing tells the user anything was clobbered.
Expected behavior
A user edit made during an agent turn must not be lost.
At minimum: detect the conflict (the store's revision already increments on every local mutation — capture it alongside the snapshot at send and compare on apply) and tell the user instead of silently overwriting. Better: rebase the agent's tool results onto the current document, or block/queue the conflicting local edit while a turn is in flight.
To Reproduce
- Open a project in the editor and ask the AI a question that takes a while and edits the document (e.g. "remove the silences").
- While the agent is still working, change something yourself — e.g. the padding in the inspector, or move a clip.
- Wait for the agent to answer.
- The change from step 2 is gone: it's absent from the timeline/inspector and from the saved
.openscreen file.
OS
Windows
Additional context
Any of the direct document editors can lose an edit this way (timeline, inspector, transcript editor, captions pane) — they all write to the same projectStore document that the agent's return value replaces.
Describe the bug
Edits made in the editor while the AI agent is running are silently lost when the agent's turn finishes.
The chat sends a full document snapshot taken at Send time, the agent folds its edits onto that snapshot in the main process, and the renderer applies the returned document wholesale —
setDocument+saveDocument— with no check that the live document has moved in the meantime. Last write wins on a stale base, so every user edit made during the turn (padding, background, a trim, a zoom, a clip move, a title change…) is overwritten on screen and on disk.Where it happens:
useProjectStore.getState().documentis captured once and passed tochatRunholder.current(electron/ai-edition/deep-agent/service.ts,DocumentHolder)applyAgentDocumentdoesstore.setDocument(parsed)thenstore.saveDocument(parsed)Note this is not the torn-file race
DocumentService.writeProjectalready guards against (that queue makes the two saves sequential and atomic — it just means the agent's stale document is written cleanly on top of the user's).The one mitigation today is that
setDocumentpushes the previous document onto the undo stack, so a single Ctrl+Z restores the user's version — but it then throws away the agent's work, and nothing tells the user anything was clobbered.Expected behavior
A user edit made during an agent turn must not be lost.
At minimum: detect the conflict (the store's
revisionalready increments on every local mutation — capture it alongside the snapshot at send and compare on apply) and tell the user instead of silently overwriting. Better: rebase the agent's tool results onto the current document, or block/queue the conflicting local edit while a turn is in flight.To Reproduce
.openscreenfile.OS
Windows
Additional context
Any of the direct document editors can lose an edit this way (timeline, inspector, transcript editor, captions pane) — they all write to the same
projectStoredocument that the agent's return value replaces.