Repository navigation
agent: turn interrupted before large write executes; retries restart from scratch and file is never created #59811
Closed as not planned
Description
Summary
In a long coding session, the agent tried to create a new ~1,200-line single-file HTML prototype with one large write tool call. The turn ended mid-response before the tool call executed, so nothing was persisted. On every retry the agent re-read source files and re-stated its full plan instead of resuming, and again never reached the write. The same zero-progress cycle repeated 5+ times; the target file was never created.
Environment
- opencode version: 2.2.0
- OS: Windows_NT 10.0.26300 (win32 x64)
- Terminal: Unavailable (terminal environment variables not set)
- Shell: cmd.exe (PowerShell for tool commands)
- Install/channel: latest
- Active plugins: hermes-notify.js (user-level config)
Reproduction
- Ask the agent to produce a large single-file artifact (~1,000+ lines / ~120 KB) in one
writecall, preceded by a detailed plan. - The turn is cut off mid-response, before the
writeexecutes. No error is shown; the turn just stops. - User says "continue". The agent re-plans from scratch (re-reads files, restates the spec) and the turn again ends before the write runs.
- Repeat. No partial output ever lands on disk, so each restart starts from zero.
Expected Behavior
- If a response is truncated, tool calls already issued in that turn should either execute or the harness should surface an explicit interruption error, instead of a silent stop.
- After an interrupted turn, the session should make it cheap to resume (e.g. a checkpoint of the last completed action) rather than nudging the model into a full re-plan.
- For large files, agent guidance should prefer chunked writes (small skeleton first, then incremental edits) so progress is preserved across interruptions.
Actual Behavior
Five-plus consecutive turns each ended before the write executed. No error was surfaced to the user; from their side the agent appeared to "hang" every time. No relevant log was captured.
Additional Context
- Frequency: consistently reproducible with one large write call in that session. Small writes and edits (a few dozen lines, config/PRD edits) completed fine throughout the same session, so the failure correlates with very large tool-call payloads and/or very long single turns.
- The session used a long summarized conversation checkpoint, which may contribute to per-turn output length pressure; no truncation error was reported anywhere.
- Workaround that worked: abandon the single large write; write a <100-line skeleton, then append the rest in several small edits. A handoff spec was also prepared so another agent could execute in small chunks.
Activity
opencodejr commentedon Oct 28, 2026
Thanks for the report, @Seeken-dai.
On 2.2.0, a reply that runs out of output tokens isn't meant to stop silently. A cut-off tool call should fail with a visible error telling the model to split large payloads into smaller calls. OpenCode should then continue on its own, and after three truncated replies in a row it should show "Response still truncated after two output token limit continuations". You saw none of that, so these turns may have ended some other way, for example a dropped or timed-out connection to the provider. To narrow it down, could you share:
anthropic/claude-...,openrouter/..., a custom endpoint), and anylimit.output/ output-token settings you have configured.opencode run.%USERPROFILE%\.local\share\opencode\log\; please include the lines around the time the turn stopped.You can reply here with the details or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.
These issues look related, though I'm not sure any of them is the same problem. They're ordered from most to least likely:
ECONNRESETafter exactly 60s, so the turn ends mid-tool-call.houleiyx commentedon Oct 29, 2026
The key detail might be how the provider stream ended: did it report an output limit, drop the connection, or finish sending the write tool call without
OpenCode executing it? Those would point to different causes.
If your provider uses a configurable API base URL, a local capture of the last few stream events could help. I’m involved with ccglass, which can record OpenCode’s requests and responses. A redacted capture alongside the provider/model and OpenCode logs would give
maintainers something concrete to trace. Splitting the file into smaller writes sounds like the right workaround for now.
Seeken-dai commentedon Oct 29, 2026
Thanks for the triage. Answers to your four questions below. Log timestamps are UTC; local time is UTC+8. Redactions: provider id/name, internal LAN address, API keys, session IDs and project paths are omitted.
1. Provider and model
npm: @ai-sdk/openai-compatible),baseURLpointing at an internal LAN gateway (redacted:http://<internal-host>:8080/v1).glm-5.3-flash(a GLM-5.3-Flash-class model). The failing model's entry has nolimitblock in user config — nolimit.outputset on our side. Other model entries in the same config set explicit limits (context 1000000 / output 128000–131072), but those were not the session model.2. Client
3. What was on screen
writetool call (~120 KB payload) never executes, no tool result, no error toast. From the user's side the turn looks hung; typing "continue" starts a fresh turn in which the model re-plans from scratch. No screenshot available retroactively; we can capture one on the next occurrence.4. Log findings (
opencode.log)For 2026-10-27 (the failing day):
06:55:39Z(14:55 local), 2–3 minutes after the last successful tool calls (spawning processat 06:52–06:53Z). The first failed turn follows that restart. The service restarted 7 times that day (boots at 01:27Z, 03:15Z, 05:55Z, 06:55Z, 09:07Z, 09:34Z, 09:36Z) — possibly related to desktop(win): background service SIGKILLed mid-turn when snapshot capture blocks /api/info for >6s -> ~60s restart loop, aborted turns #51216.session websocket failed repeatedly; using httpat09:32:29Z(17:32 local);session websocket connect failed; using httpalso present.Failed to fetch models.dev … TimeoutError after 10sat07:00:53Z— external network is flaky on this machine (same error recurs on several other days); separate from the LAN provider.2026-10-28T01:46:43ZFailed to drain Session … ECONNRESET: socket connection closed unexpectedlyat service start; a similar drain failure with a different cause appeared on 2026-10-22.One lead worth flagging
HTTP_PROXY/HTTPS_PROXYare set system-wide to a local proxy (127.0.0.1:7890), andNO_PROXYdoes not exempt the LAN provider host — so provider traffic routes through that proxy. An older log line (2026-07-22) proves the path:stream error … AI_APICallError: Cannot connect to API: connect ECONNREFUSED 127.0.0.1:7890. On the failing day there were no such errors, which is consistent with the proxy closing long-lived SSE streams cleanly — i.e. the turn ends with no fetch error and no output-token signal, matching #40146 ("truncated turns recorded as normal completions"). We own the gateway, so on the next occurrence we can capture the provider-side stream (or bypass the proxy for that host) to confirm.opencodejr commentedon Oct 31, 2026
Closing this as not planned, since we haven't heard back with the details we asked for. Thanks again for the report, @Seeken-dai.
We needed the provider and model, the client you used (TUI, desktop or
opencode run), what was on screen when a turn stopped, and logs from around that time. On 2.2.0, running out of output tokens should show a visible error and continue on its own, so a turn ending with no message at all points to another cause. Without those details we can't tell which.If it happens again, please reply here with those details or open a new issue, and we'll take another look. Your workaround, a small skeleton first and then several smaller edits, is a reasonable way to avoid it in the meantime. #56344 and #51216 may also be worth watching if your setup matches either.