[BUG] command-run host exits before parent supervision completes while continued sub-session is still active #16707

Description

I investigated a long-running opencode run --command loop9 ... workflow that stopped after iteration 3 even though iteration 4 continuation had already been dispatched and the child sub-session was still actively running.

This does not look like a normal task-level stop.

The strongest current hypothesis is:

In command-run mode, the top-level host / parent supervision path can exit before the parent session's current turn naturally finishes, even while a continuation sub-session is still active and producing progress.

In other words, the issue appears to be closer to parent-task/subagent supervision completion than to the child agent itself.

What I observed

Workflow shape

• Parent session: loop9-controller
• Child session: reused Sisyphus-Junior sub-session via continuation (task(session_id=..., prompt=...) pattern)
• Transport: opencode run --print-logs --command loop9 ... launched inside tmux by a wrapper script

Concrete symptom

At iteration 3:

• Parent explicitly decided to continue:
  • Iteration 3/5 result: FAILED. Refining into solution_v4.
• Parent successfully sent continuation to child:
  • POST /session/<child>/prompt_async
  • request completed successfully
• Child session woke up and continued doing work:
  • resolveTools
  • llm ... providerID=right modelID=gpt-5.4-high agent=Sisyphus-Junior
  • multiple message.part.updated
  • actual file reads from the next refinement step
• But the parent never naturally closed its own current turn:
  • no parent session.prompt ... exiting loop
  • no parent session.prompt ... cancel
  • no final parent-side task completed
  • no timeout-compensation follow-up prompt
• The top-level command-run process nevertheless ended, and the wrapper exited.

Result on disk:

• solution_v3/ exists
• validation_report_v3/ exists
• solution_v4/ does not exist
• no final merged/finalized output

Why this looks like a host/supervision bug rather than a child-agent bug

I checked the child session metadata before and after the iteration-3 -> iteration-4 continuation.

The child remained stable throughout the real failing case:

• provider: right
• model: gpt-5.4-high
• agent: Sisyphus-Junior
• no child-side provider error
• no model/provider drift in the failing production case

The child was still alive and processing after continuation was sent.

That makes this look much more like:

1. parent successfully dispatches continuation
2. child continues running
3. parent-side supervision/result collection does not complete
4. top-level command-run host exits too early

Important contrast with successful runs

I compared this failing run with a successful multi-iteration loop9 run.

In successful runs, the pattern is:

1. parent task status=completed
2. parent receives output JSON (output_path / status + report_path)
3. parent continues loop
4. parent enters finalization
5. parent reads manifest/index/parts
6. parent emits final merged answer
7. parent finishes normally

In the failing run, the chain breaks specifically at:

• parent task remains running
• child continues working
• parent never gets to its natural next supervision step
• command-run exits anyway

Additional public issue context that seems related

These existing issues seem directionally related:

• Sessions hang indefinitely when Task tool spawns subagents via REST API (opencode serve) #6573 — Sessions hang indefinitely when Task tool spawns subagents via REST API
• Session does not automatically return to parent after subagent execution #6491 — Session does not automatically return to parent after subagent execution
• Tasks/Subagents with Codex / OpenAI are frequently getting stuck with no timeout/retry, which then hangs the session forever #11865 — Tasks/Subagents getting stuck with no timeout/retry, hanging the session forever
• [Bug] Task tool loses session ID (task_id) when sub-agent fails or is cancelled — primary agent cannot recover #13910 — Task tool loses session ID when sub-agent fails/cancels, making recovery difficult
• Build mode stops executing before task is complete #7159 — Build mode stops executing before task is complete
• What is the deterministic way to monitor a session is completed #3815 — What is the deterministic way to monitor a session is completed
• Intermittent hang: session stays running forever until manual interrupt #14769 — Intermittent hang: session stays running forever until manual interrupt

My case is not identical to all of them, but it feels like the same family of problems:

• parent/subagent completion semantics
• supervision return path fragility
• top-level host lifecycle not matching real task-tree completion

Reproduction notes

I do not yet have a minimal reproduction as small as a 5-line script for the exact failure shape, but I was able to narrow things down substantially:

• Simple one-shot parent -> child task flows can complete normally
• Reused-session continuation paths (task(session_id=...)) appear more fragile than fresh task creation
• In a separate minimal experiment, continuation also showed execution-semantic instability (though that secondary experiment drifted into a different provider/model bug and is not the direct cause of this production case)

The production failing run used a long-running, multi-iteration command workflow with reused child-session continuation.

Requested investigation areas

I think the most promising places to inspect are:

1. opencode run --command ... host exit conditions

   • Can command-run exit while parent prompt-turn is still waiting on a continuation task?

2. Parent supervision / task completion collection

   • Is there a path where a dispatched continuation remains active, but the parent-side task state never transitions from running to completed/error/timeout?

3. Parent turn lifecycle vs top-level host lifecycle

   • Why can the host terminate without the parent session showing its normal exiting loop / cancel / idle sequence?

4. Continuation task semantics (task(session_id=...))

   • Are reused-session continuations supervised differently from fresh task creation?

Environment

• OpenCode version: 1.2.20
• OS: macOS (Darwin arm64)
• Transport: CLI command-run inside tmux
• Invocation shape: opencode run --print-logs --command loop9 ...

If helpful, I can provide a cleaned timeline of the parent/child/session events from this failing run.