Interrupted subagents lose completed work/context and return empty results to parent

[nicobao]

Description

When the main agent is interrupted while subagents have already done substantial work, the parent can receive empty subagent results and lose the useful context from those child sessions.

In the observed case, the main agent launched three parallel audit subagents. The subagent rows showed substantial activity:

• Audit API indexes: 36 tool calls, about 10m 53s
• Audit worker indexes: 8 tool calls, about 10m 53s
• Audit migration drift: 38 tool calls, about 2m 24s

After the main agent was interrupted, the parent reported that two audit subagents returned empty and only the migration-drift subagent returned findings. Clicking into the subagents showed that they had done work, but there was no final summary/context available to pass back to the main agent.

The practical impact is that interruption can waste long-running subagent work. The main agent has to manually redo the investigation even though the child sessions contain useful intermediate work.

This seems different from a normal empty-result case because the trigger is user interruption / incomplete child termination. The child work exists, but the parent gets no best-effort partial result, transcript summary, or diagnostic explaining what was preserved.

Observed behavior

From the screenshots/transcript:

User: the subagents didn't finish?

Assistant: They didn't provide useful results: two audit subagents returned empty, only the migration-drift subagent returned findings. I'm not waiting on them; I'm continuing the index/performance audit directly from the code and schema.

User: is that because i interrupted ...?

Assistant: Probably, yes. The two subagents returning empty usually means they were interrupted or didn't complete cleanly, not that there were no findings. I'm proceeding manually and will only use findings I verify directly in the code.

User: oh but that's such a waste, that means i shouldn't interrupt?

Assistant: Interrupting is fine. It can waste a subagent run, but it doesn't corrupt anything or block the work; I just switch to direct inspection or relaunch only if it's worth it.

Expected behavior

Interrupting the main agent should not silently discard all useful subagent work from the parent agent's perspective.

At minimum, when a subagent has performed tool calls or produced intermediate assistant/tool content but does not complete with a final text summary, the parent should receive a diagnostic or recoverable context instead of an empty result, for example:

• child session id / task id
• status such as interrupted, aborted, incomplete, or no final text part
• part/tool-call summary
• last meaningful assistant text if available
• a best-effort summary generated from the child transcript, if safe
• a way for the parent to inspect the interrupted child session context before redoing work

The important property is that the main agent should be able to distinguish:

• no findings
• interrupted before final response
• subagent did work but no final text result was serialized
• provider/runtime error
• UI-only visibility issue

Steps to reproduce

1. Ask the main agent to launch multiple subagents for a non-trivial audit/research task.
2. Let the subagents run long enough to perform multiple tool calls and accumulate useful work.
3. Interrupt the main agent while the subagents are still running or before all subagents have returned final summaries.
4. Ask the main agent whether the subagents finished and what they returned.
5. Open the subagent views and observe that they contain work, but the parent reports empty/missing results and proceeds by redoing the work manually.

Screenshot and/or share link

Screenshots show:

• three parallel audit subagents with 36, 8, and 38 tool calls
• main agent status as interrupted
• parent reporting two subagents returned empty
• parent attributing the empty results to interruption / incomplete clean termination
• parent explaining that interruption can waste the subagent run and force direct reinspection

See them above.

Related issues

• TaskTool returns no diagnostic context when subagent result text is empty or missing #24447: TaskTool returns no diagnostic context when subagent result text is empty or missing
• Interrupting the main agent does not stop background subagents #28738: interrupting the main agent does not stop background subagents
• [FEATURE]: parent agent should observe background subagent's real-time progress and streaming output #27898: parent agent should observe background subagent real-time progress and streaming output
• empty subagent ui #28171: empty subagent UI
• [Bug] GPT OSS 120B subagent stops mid-reasoning and returns empty result after several tool calls #27210 and Ollama subagent executes tool calls correctly but always returns empty text to orchestrator #18423: subagents can do work/tool calls but parent receives empty result

This issue is specifically about preserving or surfacing useful child-session context after user interruption so the main agent does not have to redo substantial completed subagent work.

Version/config notes

This was observed on opencode 1.15.10, so it appears to still be present after the related 1.15.4 / 1.15.6 reports.

Relevant local config notes:

• ~/.config/opencode/opencode.json does not declare a plugin array.
• Figma and Playwright MCP servers are enabled.
• OCX is in use.
• OCX receipt shows notify-kitty from https://nicobao.github.io/opencode-notify and kdco-primitives from https://registry.kdco.dev installed under ~/.config/opencode/plugins/.
• The notification plugin is unlikely to be the cause because this bug is about task/subagent result propagation, but it is included here for completeness.

Plugins

Using OCX. No explicit plugin entry in opencode.json, but OCX-installed plugins are present: notify-kitty and kdco-primitives under ~/.config/opencode/plugins/.

OpenCode version

1.15.10

Operating System

macOS 15.7.4

Terminal

kitty

[nodakai]

My prompt template now includes this text "if the reviewer subagent returned a nonempty unambiguous approval then..." as a workaround

[github-actions]

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.