TUI/task runs can stall after last completed tool; child tasks may spawn empty assistant run and hang parent #21250

Summary

In TUI, some runs visibly finish their useful work (final text is already printed and the last tool is already marked completed), but the run stays in Thinking for another 45-66 seconds before step-finish arrives.

In more severe cases, task/subagent runs complete useful work, then immediately create an extra empty assistant message (part_count = 0, completed = null), and the parent session hangs forever waiting for the task to finish.

This looks related to existing subagent / run-finalization hangs, but the timeline here is more specific:

• visible work is already done
• tools are already completed
• then there is a long silent tail before step-finish
• or a child session creates one more empty assistant run and never closes

Possibly related to:

• Explore subagent hangs indefinitely with Anthropic Claude Opus 4.6 -- no timeout or recovery #13841
• opencode run hangs after completing tool calls — process never exits #17516

Environment

• OpenCode 1.3.13
• TUI (opencode)
• macOS
• repro seen with:
  • openai/gpt-5.4
  • anthropic/claude-opus-4-6
• also involves task subagents in some cases

What I observed

Case 1: long silent tail after last completed tool

In one parent session, the previous successful run had this timeline:

• 03:04:50 step-start
• 03:04:51–03:05:19 normal reasoning
• 03:05:19 final text is already present
• 03:05:19 todowrite is already completed
• 03:06:25 only then step-finish arrives

So the useful work ended at 03:05:19, but the run stayed open for ~66 seconds with no new reasoning, no new tools, no subagents.

I also saw an earlier run in the same session with the same pattern:

• last ssh-edge-prod_exec completed at 02:58:59
• step-finish only arrived at 02:59:46

That is another ~47 second silent tail after the last completed tool.

Case 2: child task completes work, then spawns an empty assistant run

In a later run in the same session, the parent run did:

• ssh-edge-prod_exec completed
• google_search completed
• launched two task tools

Those tasks created child sessions. In each child session, useful assistant outputs were produced normally, but then an additional assistant message was created with:

• part_count = 0
• completed = null
• no text
• no tools
• no reasoning

After that, the parent remained stuck waiting on the tasks.

So from the user's perspective:

1. the child appears to have already answered
2. but the parent is still Thinking
3. because the child spawned one more empty assistant run that never closes

Why this seems like a runtime bug, not just a slow model

For the delayed step-finish cases:

• the final text was already rendered
• the last tool was already marked completed
• there were no additional parts after that until step-finish

For the subagent case:

• child sessions had already produced valid assistant outputs
• then they created an extra empty assistant message
• the parent task never resolved

This does not look like normal inference latency. It looks like run-finalization / task-completion bookkeeping is getting stuck.

Repro shape

I do not yet have a tiny standalone repro, but the pattern is consistent in a real session that:

• uses task subagents
• includes normal tools like ssh-edge-prod_exec, google_search, todowrite, read, grep, glob
• runs on TUI with gpt-5.4 and claude-opus-4-6

Expected behavior

• once the last tool is completed and no more parts are produced, step-finish should follow immediately (or near-immediately)
• if a child task has already produced its final assistant output, it should not create a trailing empty assistant run
• parent tasks should either complete or fail explicitly, not hang behind an invisible empty child run

Actual behavior

• some runs sit in Thinking for 45-66s after the last completed tool
• some subagent sessions create an extra empty assistant message and never complete
• parent session remains stuck waiting on the child task

If helpful, I can follow up with a sanitized DB timeline / message+part dump for the affected session.