Repository navigation
Description
Description
When opencode run executes a prompt whose main work is a tool call, the parent session does not terminate immediately after the tool result completes.
Instead, the parent session performs one additional assistant turn and only then exits. In exported session data, this extra turn is an assistant message with:
finish: "stop"- empty
text
This makes tool-driven runs feel like they linger after completion, even when there is no additional user-visible output to produce.
Plugins
No extra global plugins in the control repro. The repro uses a local project plugin only to provide the tool call target.
OpenCode version
1.2.27
Steps to reproduce
- Prepare a temp repo with a tool-call target available.
- Run:
XDG_CONFIG_HOME="$cfgdir" /home/leslie/.openclaw/tools/node/bin/opencode run --print-logs -m github-copilot/gpt-5.3-codex \ 'Call ability_run to execute development/code-change with inputs {"task_id":"probe_medium4","objective":"Update API handler and response type","acceptance_criteria":"handler returns 201;response type includes message","affected_files":"src/api/handler.ts,src/api/types.ts","validation_command":"grep -q 201 src/api/handler.ts && grep -q message src/api/types.ts"}. After the tool result, stop immediately.'
- Export the parent session after the run completes.
- Observe:
- runtime log still advances another parent-session prompt step before exit
- exported session contains a final assistant message with
finish: "stop"and empty text
Screenshot and/or share link
No share link. Local evidence was captured in a control repro log and session export.
Operating System
Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 GNU/Linux
Terminal
bash (GNU bash 5.2.21) under WSL2
Additional context
Expected behavior:
- after the tool result completes, the parent session should exit immediately if there is no remaining text or tool work
Actual behavior:
- parent session performs one extra assistant turn before exiting
- in the control repro, the runtime log shows
step=1, thenstep=2, thenexiting loop - exported session structure is:
userassistantwithfinish="tool-calls"assistantwithfinish="stop"and empty text
This does not appear to corrupt tool output or workflow artifacts. The tool result is correct and the session exits cleanly after the extra empty stop-turn. The issue appears to be runtime completion semantics after tool-calls.
Possible fix direction:
- if all tool calls are complete and the next assistant turn would produce no text and no additional tool calls, CLI could terminate immediately instead of emitting an extra empty
finish="stop"assistant turn
Activity
github-actions commentedon Mar 26, 2026
This issue might be a duplicate of an existing issue. Please check:
finish=stop, triggering prefill error on claude-opus-4-6 #17982: Describes the same root cause — the prompt loop continues to step N+1 afterfinish=stop, when it should terminate. That issue observed the bug as a prefill error on claude-opus-4-6, but the underlying mechanism (loop not gating continuation on finish reason) is the same as what you're reporting here.Leslie-ller commentedon Mar 26, 2026
Bot suggestion is correct. This is a duplicate of #17982. I have copied the additional evidence there and am closing this duplicate.