bug(desktop): Editing and resending a follow-up fails after Agent Graph completion #5331

What happened

In a Desktop session using Swarm mode, all three child tasks completed, the Agent Graph was finished, and the parent agent produced its final summary. I then asked a follow-up question and received an answer. Editing that follow-up question and resending it failed with a generic toast, translated from the Chinese UI:

Operation failed
The task operation failed. Please try again later.

Runtime Host returned operation_unavailable, reporting that retained Agent Graph children lacked terminal results. However, the child terminal events and final results were present in SQLite. Three attempts in the affected session produced the same error.

Expected: Create a new version in the same session revision family, retain the history before the edited turn and its valid child-result references, and generate a response to the edited question. The original version should remain available.

Actual: Revision creation is rejected during preflight, before a new model invocation starts. The original answer remains available, but editing and resending cannot complete.

How to reproduce

The following describes the observed workflow. Model tool choices may affect whether it follows the same path; a fully deterministic end-to-end reproduction from a fresh session has not yet been established.

1. Run Desktop from source, create a session, and enable Swarm mode in a workspace containing multiple packages to review.
2. Request a parallel review of several packages. The original prompt, translated from Chinese, was: “Review these three packages and provide concrete evidence: storage, runtime-host, runtime.”
3. Have the parent agent schedule three child tasks through update_agent_graph, then call yield_agent_graph. Wait for all children to complete, for the parent to read their results through agent_output, and for it to commit Graph finish and produce its final summary.
4. Ask a normal follow-up question in the same session, such as “How was the Agent Graph invoked and executed?” Wait for the answer to finish.
5. Edit the user question from step 4 and resend it.
6. Observe the failure toast. The failing operation in the logs is session.revision.create.

The edited question comes after Graph completion. The retained history includes the scheduling turn, result reads, and summary turn; the revision boundary does not exclude the child results. In this session, those tool results were persisted as ToolResultContent.kind = json.

Environment

• Maka: 0.2.0, development build; diagnostic report identifies dev @ 3cfcb09
• Surface: Desktop → Runtime Host
• OS: macOS, Darwin 23.2.0, x64
• Electron: 43.4.1
• Node.js: 24.18.1, as reported by the running instance
• Locale: zh-CN
• Orchestration mode: Swarm
• Model: glm-5.3, using the zai-coding-plan connection
• Storage: runtime.sqlite in the local default workspace
• Runtime Host connection was ready at the time of the error; the diagnostic report recorded no Host process exits.

Logs, screenshots, or additional context

Relevant log excerpt; timestamps are UTC:

[2026-09-13T16:11:38.230Z] ERROR Error occurred in handler for 'sessions:reviseBeforeTurn':
RuntimeHostOperationError: Session revision requires a terminal result for every retained Agent Graph child
{
  operation: 'session.revision.create',
  code: 'operation_unavailable'
}

The same error also occurred at 2026-09-13T10:48:42.650Z and 2026-09-13T10:48:48.568Z.

Read-only inspection of a consistent SQLite snapshot confirmed:

• All three children had completed terminal events. The last child completed at 2026-09-13T08:08:16.902Z.
• agent_graph_schedule_updates contained a finish update with closes_graph = 1, committed at 2026-09-13T08:09:13.244Z, selecting three result records.
• The parent summary completed at 08:10:37.432Z, and the follow-up answer completed at 09:36:54.626Z on the same day, both before the first resend failure.
• The retained history contained four agent_output responses covering three children. The runtime review result was read twice; both reads referenced the same Session, Run, Turn, and result record ID. No fourth child task was created.
• PRAGMA quick_check returned ok; foreign_key_check returned no rows.

Identified rejection cause

In packages/runtime/src/conversation-copy.ts, conversationCopyLinkedChildReferences() only extracts child references from results whose top-level kind is subagent or agent_swarm. The actual persisted agent_output structure in this session was:

kind: json
value.execution.sessionId: <childSessionId>
value.invocation.runId: <runId>
value.invocation.turnId: <turnId>
value.invocation.terminalEvent.status: completed
value.result.status: completed
value.result.resultRecordId: <committed graph result record>
value.result.artifactIds: []

The terminal references are present inside the JSON value but are not recognized by the collector. In packages/runtime-host/src/server/session-revision-graph-references.ts, prepareAgentGraphRevisionReferences() then finds three direct child Sessions belonging to retained parent turns, but zero collected child references, and returns the error above. This rejection occurs before Graph state or child Run terminal status is read.

Verification scope

An isolated reproduction supplied real snapshot data to the actual message projection, history slicing, copy planning, reference collection, and Graph reference validation functions:

The isolated verification used source commit 6ce9c72c3 from the investigation. The relevant collection and validation logic was identical to the reported build, 3cfcb09. It used real child invocation data and stubbed Graph state reads to return the terminal state confirmed in SQLite. This verifies the rejection cause and the conditions under which this check passes; it does not establish that the entire revision transaction and subsequent model invocation succeed.

Fix considerations

json is a valid result type. Simply changing the existing object's kind to subagent or agent_swarm fails schema validation because the required fields for those result types are missing. Revision handling needs to recognize and validate the actual asynchronous Graph result references and preserve or rewrite references appropriately during copying.

A fix should also support existing sessions whose results were already persisted as JSON, including archived results. Changing only future agent_output responses would leave those sessions affected. A regression test should cover the complete workflow: asynchronous Graph completion → ordinary follow-up → edit and resend.