Interrupted streamed apply_patch call leaves orphaned tool state and leaks internal preparation text

[doomsday616]

Description

While working in an interactive OpenCode TUI session, the assistant repeatedly got stuck while preparing an apply_patch call. The UI briefly leaked internal/tool-preparation text such as:

• Need patch lines...
• ~ Preparing patch...
• ▣ Build · GPT-5.5

No actual tool execution followed. The session returned to idle / stopped progressing.

This happened during a Windows local script editing task involving PowerShell/VBS/CMD files under a path with spaces and non-ASCII characters:

C:\\Users\\<user>\\Desktop\\<local-project>\\

I checked the local OpenCode logs and database. The relevant entries show that OpenCode recorded an interrupted/orphaned apply_patch tool call before any patch input was received:

WARN ... service=session.prompt session.id=ses_17f16cb17fferKVQxLeeY3CXO3 messageID=msg_e904b15de001uKlUuk0BC1CoZK tool=apply_patch callID=call_l3e8ODy4J0Cer9xH7QSOGC22 loop exit with orphaned interrupted tool
WARN ... service=session.prompt session.id=ses_17f16cb17fferKVQxLeeY3CXO3 messageID=msg_e905063ea001iD6jKmLWAFBd0r tool=apply_patch callID=call_zZ7xhBdiIknyy835gw1xHP1v loop exit with orphaned interrupted tool

The corresponding part.data rows in opencode.db look like this:

{
  "type": "tool",
  "tool": "apply_patch",
  "callID": "call_l3e8ODy4J0Cer9xH7QSOGC22",
  "state": {
    "status": "error",
    "input": {},
    "raw": "",
    "error": "Tool execution aborted",
    "metadata": { "interrupted": true }
  }
}

There were also upstream streaming errors around the same session:

AI_APICallError ... providerID=github-copilot modelID=gpt-5.5 ... cause.code=ECONNRESET ... url=https://api.githubcopilot.com/responses
ERROR ... stream error
ERROR ... error=The operation timed out

So this looks like a streamed tool call was interrupted before its arguments were complete, then OpenCode left an orphaned interrupted tool state and the TUI exposed internal preparation text instead of showing a clean error/retry state.

Related but not identical: #22222. That issue is about acpx/non-interactive mode on an older OpenCode version. This report is for the interactive TUI on Windows with OpenCode 1.15.13 and GitHub Copilot GPT-5.5, with concrete orphaned interrupted tool evidence.

One additional safety concern: earlier in the same work, the assistant mistakenly tried to use apply_patch to delete a large .wim file (~600 MB), which caused OpenCode to crash. It would be good if apply_patch refused large/binary files instead of trying to process them.

Plugins

Built-in GitHub Copilot provider/plugin. No MCP involved.

OpenCode version

1.15.13

Steps to reproduce

I do not have a minimal deterministic repro yet, but this happened multiple times in one real session.

Likely repro path:

1. Start an interactive OpenCode TUI session on Windows.
2. Use GitHub Copilot gpt-5.5 with the build agent.
3. Work on a local task that requires multi-file edits with apply_patch.
4. Have the model generate a relatively large/multi-file patch.
5. Interrupt the network stream, wait for a Copilot timeout, or otherwise trigger a stream interruption while the model is still producing the tool-call arguments.
6. Observe that the UI may show internal preparation text and no tool actually runs.
7. Check logs for loop exit with orphaned interrupted tool.
8. Check opencode.db for an apply_patch part with input:{}, raw:"", and metadata.interrupted:true.

Screenshot and/or share link

No screenshot/share link. The local logs and DB evidence above are from session ses_17f16cb17fferKVQxLeeY3CXO3.

Operating System

Windows 11 Insider / Windows NT 10.0.26200.0

Terminal

PowerShell 7 / Windows terminal environment

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Sessions permanently stuck after server restart or stream interruption — no startup recovery for orphaned messages/tool parts #19023: Sessions permanently stuck after server restart or stream interruption — no startup recovery for orphaned messages/tool parts (covers the same orphaned interrupted tool state in the DB and stuck session behavior after a stream interruption)

[doomsday616]

Thanks for the pointer. #19023 is definitely related, but I think this report adds a slightly different failure mode / symptom:

• No server restart was involved in this case. The active Copilot/GPT-5.5 response stream failed/timed out while the model was still producing an apply_patch tool call.
• The resulting DB state was not a long-running/pending tool part. It was already finalized as an interrupted tool with status:"error", but with empty arguments: input:{}, raw:"", error:"Tool execution aborted", metadata.interrupted:true.
• The TUI then exposed internal preparation text (Need patch lines..., Preparing patch...) and returned to idle without a clear user-facing error/retry state.

So #19023 seems to cover the broader orphaned-message/tool-part recovery problem. This issue is specifically about the streamed tool-call argument assembly path and the TUI rendering/UX when an apply_patch call is interrupted before its arguments are complete.

If maintainers prefer to track all orphaned/interrupted tool states under #19023, this can be closed as duplicate, but I wanted to keep this case visible because the observable bug is not permanent Thinking after restart; it is an interrupted streamed apply_patch producing an empty-input tool part and leaking preparation UI text.

[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.