Skip to content

Tool execution aborted/terminated #26063

Closed as not planned
Closed as not planned
Tool execution aborted/terminated#26063
Assignees
jlongster

Description

@aagarin39
aagarin39
opened on May 6, 2026

Description

Bug Report:

Environment:

  • Provider: LM Studio (opencode-compatible)
  • Model: Qwen3.6-35b-A3B
  • Endpoint: http://127.0.0.1:1234/v1
  • OpenCode version: 1.14.39
  • Error date: 05.05.2026

Description:
Tool execution aborted/terminated — occurs with local LM Studio models. Agent freezes prematurely during tool execution, requires manual "continue" to proceed.

Steps to reproduce:

  1. Run opencode with LM Studio provider
  2. Use Qwen3.6-35b-A3B or similar local model
  3. Execute task with tool calls (bash, read, edit)
  4. Tool execution aborts after ~30-60 seconds

Expected behavior:
Tool execution should complete without manual intervention.

Related issues:

Config:

{
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "options": { "baseURL": "http://127.0.0.1:1234/v1" },
      "models": {
        "qwen3.6-35b-a3b": {
          "name": "Qwen3.6-35B-A3B",
          "limit": { "context": 100000, "output": 15000 }
        }
      }
    }
  }
}

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

Activity

  1. github-actions
    assigned
    jlongster
    on May 6, 2026

  2. github-actions commented on May 6, 2026

    @github-actions
    github-actionsBot
    on May 6, 2026 – with GitHub Actions
    Contributor

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

    If this is a distinct issue (e.g., specific to local LM Studio models vs. cloud Claude models), please add clarifying details about what makes it different. Otherwise, consider adding your information to the existing issue.

    Also note #17307 which covers aggressive timeouts with local models, which may be related to your use case.

  3. aagarin39 commented on May 7, 2026

    @aagarin39
    aagarin39
    on May 7, 2026 via email
    Author

  4. aagarin39 commented on May 7, 2026

    @aagarin39
    aagarin39
    on May 7, 2026 via email
    Author

  5. aagarin39 commented on May 8, 2026

    @aagarin39
    aagarin39
    on May 8, 2026
    Author
    Image

    Long recording is also stopped. In general, the problem with all expectations when working with local llm systems.

  6. aagarin39 commented on May 8, 2026

    @aagarin39
    aagarin39
    on May 8, 2026
    Author

    2026-05-08 12:59:47 [INFO]
    [qwen3.6-35b-a3b] Prompt processing progress: 100.0%
    2026-05-08 13:05:13 [INFO]
    [LM STUDIO SERVER] Client disconnected. Stopping generation... (If the model is busy processing the prompt, it will finish first.)
    2026-05-08 13:05:13 [INFO]
    [qwen3.6-35b-a3b] Finished streaming response

  7. aagarin39 commented on May 8, 2026

    @aagarin39
    aagarin39
    on May 8, 2026
    Author

    With each update, this limit of 5 minutes always appears. any update with a large volume of changes will incur a five-minute limit for local LLMs.

  8. mironoff2007 commented on May 9, 2026

    @mironoff2007
    mironoff2007
    on May 9, 2026

    1.14.41 same problem, using desktop version and 27B or 35B
    1.14.19 cli works fine

  9. aagarin39 commented on May 9, 2026

    @aagarin39
    aagarin39
    on May 9, 2026 via email
    Author

  10. yu-zou commented on May 9, 2026

    @yu-zou
    yu-zou
    on May 9, 2026

    Same problem on v1.14.41

  11. JumpmanSr commented on May 11, 2026

    @JumpmanSr
    JumpmanSr
    on May 11, 2026

    v1.14.48 Desktop, checking the logs it seems like there's a timeout happening in Undici. Anyway we can change this? I have slow inference but it will produce results after thinking for some time but the 5 minute timeout has caused me nothing but problems. Probably gonna downgrade to 1.14.41 CLI or something. Also using a local network for my API.

  12. aagarin39 commented on May 11, 2026

    @aagarin39
    aagarin39
    on May 11, 2026 via email
    Author

  13. Jinxatron commented on May 14, 2026

    @Jinxatron
    Jinxatron
    on May 14, 2026

    Yeupp, running on desktop, keep getting this on heavy context processing on local model.

  14. akmi1975 commented on May 16, 2026

    @akmi1975
    akmi1975
    on May 16, 2026

    a similar problem in opencode version 1.15.1

  15. mezenin commented on May 31, 2026

    @mezenin
    mezenin
    on May 31, 2026

    Same at 1.15.13

  16. 5 remaining items

  17. aagarin39 commented on Jun 22, 2026

    @aagarin39
    aagarin39
    on Jun 22, 2026
    Author

    2026-06-22 11:02:49 [INFO]
    [qwen3.6] Streaming response...
    2026-06-22 11:02:50 [INFO]
    [qwen3.6] Prompt processing progress: 0.0%
    2026-06-22 11:03:08 [INFO]
    [qwen3.6] Prompt processing progress: 2.0%
    2026-06-22 11:03:24 [INFO]
    [qwen3.6] Prompt processing progress: 4.0%
    2026-06-22 11:03:40 [INFO]
    [qwen3.6] Prompt processing progress: 6.0%
    2026-06-22 11:03:56 [INFO]
    [qwen3.6] Prompt processing progress: 8.0%
    2026-06-22 11:04:16 [INFO]
    [qwen3.6] Prompt processing progress: 10.0%
    2026-06-22 11:04:34 [INFO]
    [qwen3.6] Prompt processing progress: 12.0%
    2026-06-22 11:04:49 [INFO]
    [qwen3.6] Prompt processing progress: 14.0%
    2026-06-22 11:05:06 [INFO]
    [qwen3.6] Prompt processing progress: 16.0%
    2026-06-22 11:05:22 [INFO]
    [qwen3.6] Prompt processing progress: 18.0%
    2026-06-22 11:05:37 [INFO]
    [qwen3.6] Prompt processing progress: 20.0%
    2026-06-22 11:05:53 [INFO]
    [qwen3.6] Prompt processing progress: 22.1%
    2026-06-22 11:06:10 [INFO]
    [qwen3.6] Prompt processing progress: 24.1%
    2026-06-22 11:06:27 [INFO]
    [qwen3.6] Prompt processing progress: 26.1%
    2026-06-22 11:06:46 [INFO]
    [qwen3.6] Prompt processing progress: 28.1%
    2026-06-22 11:07:04 [INFO]
    [qwen3.6] Prompt processing progress: 30.1%
    2026-06-22 11:07:21 [INFO]
    [qwen3.6] Prompt processing progress: 32.1%
    2026-06-22 11:07:39 [INFO]
    [qwen3.6] Prompt processing progress: 34.1%
    2026-06-22 11:07:53 [INFO]
    [LM STUDIO SERVER] Client disconnected. Stopping generation... (If the model is busy processing the prompt, it will finish first.)
    2026-06-22 11:07:53 [INFO]
    [qwen3.6] Prompt processing progress: 34.1%
    2026-06-22 11:07:53 [INFO]
    [qwen3.6] Finished streaming response

  18. aagarin39 commented on Jun 22, 2026

    @aagarin39
    aagarin39
    on Jun 22, 2026
    Author

    Issue: Tool execution aborted prematurely with local models (LM Studio / @ai-sdk/openai-compatible)

    Describe the bug

    When using a local model via LM Studio (@ai-sdk/openai-compatible), tool execution (bash, file operations) gets aborted mid-execution. The agent returns Tool execution aborted or Tool execution terminated by the model, resulting in broken sessions.

    To Reproduce

    1. Configure LM Studio as provider with @ai-sdk/openai-compatible
    2. Use any local model (tested with qwen3.6-35b-a3b)
    3. Ask the agent to execute a tool that takes more than ~250ms (e.g., git log, npm install, file search)
    4. Tool gets aborted mid-execution

    Root cause (from source code analysis)

    The issue is in packages/opencode/src/session/processor.ts — the cleanup() function:

    const cleanup = (deadline: number) =>
  Effect.gen(function*() {
    // ...
    yield* Effect.all(tools, { concurrency: "unbounded" }).pipe(
      Effect.timeout("250 millis"),
    )
    // Any tool still pending after 250ms gets marked as "Tool execution aborted"
    for (const tool of tools) {
      if (/* still pending */) {
        yield* tool.fail(`Tool execution aborted: using "${result.model}"`)
      }
    }
  })

    The 250ms timeout is too aggressive. For local models, tool execution often exceeds this window, causing premature cancellation.

    A contributing factor is in packages/opencode/src/session/llm.ts — Stream.scoped creates an AbortController that calls ctrl.abort() when the stream scope closes. If the scope closes while tools are still in-flight (between LLM call iterations), the abort signal propagates through the AI SDK and terminates tool execution.

    Additional context: packages/core/src/tool/bash.ts sets DEFAULT_TIMEOUT_MS = 120000 (2 minutes), showing the expected tool lifecycle is much longer than 250ms.

    Expected behavior

    Tools should be allowed to complete their execution before cleanup, or given a reasonable timeout (matching the tool's configured timeout, e.g., 120s for bash). The 250ms window should be either:

    • Removed (let tools finish naturally)
    • Increased to match tool-level timeouts (60-120s)
    • Made configurable via provider/model options

    Environment

    • OpenCode version: 1.17.9 (prebuilt binary, npm global install)
    • OS: Windows 11
    • Provider: LM Studio 0.3.13 (@ai-sdk/openai-compatible)
    • Model: qwen3.6-35b-a3b (local)

    Related issues

    Suggested fix location

    • packages/opencode/src/session/processor.ts:cleanup() — increase or remove the 250ms Effect.timeout
    • packages/opencode/src/session/llm.ts — decouple AbortController lifecycle from stream scope to avoid aborting in-flight tool execution

  19. AchwaqKhalid commented on Jun 25, 2026

    @AchwaqKhalid
    AchwaqKhalid
    on Jun 25, 2026

    As of v1.17.11 still no fix.

  20. Unamelable commented on Jun 26, 2026

    @Unamelable
    Unamelable
    on Jun 26, 2026

    Yeah, doing my project causes terminated error. would be handy to apply bandage to write "Terminated: Seems like you doing lot of work, wait 5 minutes and then continue." instead just "terminated"

  21. Mte90 commented on Jul 1, 2026

    @Mte90
    Mte90
    on Jul 1, 2026

    I have that issue since various releases on linux...

  22. Mte90 commented on Jul 1, 2026

    @Mte90
    Mte90
    on Jul 1, 2026
    $ python3 << 'EOF'
binary_path = '/tmp/opencode.backup'
output_path = '/tmp/opencode.patched.bin'

with open(binary_path, 'rb') as f:
    data = bytearray(f.read())

print(f"Binary size: {len(data):,} bytes")

# Find the exact pattern: h.timeout("250 millis")
# Original: h.timeout("250 millis") = 21 bytes
# Replacement must be EXACTLY 21 bytes

original = b'h.timeout("250 millis")'
print(f"Original length: {len(original)} bytes")

# Option 1: "60 seconds" = 10 chars, same as "250 millis" = 10 chars
replacement = b'h.timeout("60 seconds")'
print(f"Replacement length: {len(replacement)} bytes")

if len(original) != len(replacement):
    print("ERROR: Lengths don't match!")
    exit(1)

idx = data.find(original)
if idx == -1:
    print("ERROR: Pattern not found!")
    exit(1)

print(f"Found at offset: {idx:#x}")
data[idx:idx+len(original)] = replacement
print(f"Replaced successfully")

# Write the patched binary
with open(output_path, 'wb') as f:
    f.write(data)
    
print(f"\nPatched binary saved to: {output_path}")

# Verify
with open(output_path, 'rb') as f:
    verify = f.read()

if verify[idx:idx+len(replacement)] == replacement:
    print("✓ Verification passed: patch applied correctly")
else:
    print("✗ Verification failed: patch not applied")

# Check sleep calls are untouched
sleep_count = verify.count(b'd.sleep("250 millis")')
print(f"✓ {sleep_count} sleep('250 millis') calls remain unchanged (expected: 2)")
EOF

Binary size: 167,577,728 bytes
Original length: 23 bytes
Replacement length: 23 bytes
Found at offset: 0x5bfb017
Replaced successfully

Patched binary saved to: /tmp/opencode.patched.bin
✓ Verification passed: patch applied correctly
✓ 2 sleep('250 millis') calls remain unchanged (expected: 2)

    this script patches the linux version with a different timeout, I see that now takes more in "preparing edit" but fails anyway

  23. harikiran-lab commented on Jul 1, 2026

    @harikiran-lab
    harikiran-lab
    on Jul 1, 2026

    It seems to be an issue on LMStudio. I switched to Unsloth inference and it resolved write file turnication issue.

  24. Mte90 commented on Jul 1, 2026

    @Mte90
    Mte90
    on Jul 1, 2026

    I tried also with the free models on opencode, and other providers.

    I think that is something like waiting the model respond with the whole function tool and that the agent parse that but changing the various timeout didn't fixed.

  25. Mte90 commented on Jul 2, 2026

    @Mte90
    Mte90
    on Jul 2, 2026

    I invested all the day do try and test with a session where I always this error also on resume #34952

  26. Huojunning commented on Jul 8, 2026

    @Huojunning
    Huojunning
    on Jul 8, 2026

    我查阅日志后定位到两个任务中断的根源问题：
    初始请求超时问题：通过新增配置 provider:{"options":{"timeout":6000,"headerTimeout":false,"chunkTimeout":60000}} 调整超时参数，解决了链路超时报错；
    Git 版本兼容问题：旧版 Git 不支持--sparse稀疏克隆参数，执行拉取流程时直接中断，升级 Git 版本后兼容该参数。
    目前已完成超时参数配置调整与 Git 版本升级，两处问题均修复，流程运行正常。

    After checking the logs, I found two root causes leading to task interruption:
    Initial request timeout issue: I added the config provider:{"options":{"timeout":6000,"headerTimeout":false,"chunkTimeout":60000}} to adjust timeout parameters, which fixed the link timeout errors.
    Git compatibility issue: The old Git version did not support the --sparse flag and broke the clone process. I upgraded Git to a newer compatible version.
    Both issues have been resolved by configuring the timeout options and updating Git, and the workflow runs smoothly now.

  27. PowerfulShell commented on Jul 12, 2026

    @PowerfulShell
    PowerfulShell
    on Jul 12, 2026

    Yeupp, running on desktop, keep getting this on heavy context processing on local model.

    exactly, i had this issue too, latest version

  28. wzg0911 commented on Jul 12, 2026

    @wzg0911
    wzg0911
    on Jul 12, 2026

    The tool execution freezing mid-way with local LM Studio models is a known pain point. The agent appears to hang because there's no heartbeat/timeout mechanism between the frontend and the local model server.

    A pattern that works in production:

    Timeout + restart pipeline — Set a hard timeout on each tool call (e.g., 120s). If the call exceeds the timeout, automatically terminate the stuck call and restart from the last checkpoint. This prevents the agent from freezing indefinitely.

    Dead-man's switch — Periodically the agent must emit a progress signal. If 3 consecutive heartbeats are missed, assume the tool call is hung and auto-restart.

    Graceful model fallback — If the local model keeps freezing, auto-failover to an API-based model for that specific call, then resume with local model on the next call.

    I built a free diagnostic tool that can scan agent configs for these reliability gaps (timeouts, fallback chains, stuck detection): ark-6ek.pages.dev/diagnose
    30s, no signup.

  29. aagarin39 commented on Aug 21, 2026

    @aagarin39
    aagarin39
    on Aug 21, 2026
    Author

    Follow-up on v1.18.20 behavior change:

    After updating to v1.18.20, the hard abort (UnknownError: terminated) is gone — but the new retry behavior introduced a different problem on long sessions with local models:

    What happens now:

    During a long session, the provider response ends with finish_reason: network_error (or similar)
    Instead of aborting, opencode retries the entire request
    The model restarts its reasoning from scratch — all thinking progress is lost
    Prompt cache is preserved, so the replay is faster than a cold start, but the model still re-generates the full reasoning chain
    Impact on local models (LM Studio):

    Reasoning chains can take minutes; losing them on every network hiccup makes long sessions impractical
    The retry is transparent (no visible error), so the user just sees the agent "thinking again" — easy to miss that progress was reset
    Suggestion: consider resuming from the last stable state (e.g., keep completed tool results and only regenerate the interrupted step) instead of replaying the full turn, or make the retry budget/configurable for slow local providers.

  30. thdxr commented on Oct 11, 2026

    @thdxr
    thdxr
    on Oct 11, 2026
    Member

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

  31. thdxr
    closed this as not plannedon Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions