Repository navigation
Regression after 1.3.12: tool-call failures (PowerShell + malformed JSON behavior) on official Kimi provider #20577
Description
Description
Title
Regression after 1.3.12: tool-call failures (PowerShell + malformed behavior) on official Kimi provider
Description
I’m seeing a regression between opencode-ai@1.3.12 and newer builds.
Repro matrix
npx opencode-ai@1.3.12→ ✅ works- newer build (latest) → ❌ tool-call errors / malformed behavior
- only reproduces with official Kimi coding-plan/provider
- same Kimi model via other providers works fine
- also seeing issues specifically involving PowerShell tool execution
Symptoms
- tool calls fail or behave incorrectly
- sometimes looks like malformed tool-call flow (bad follow-ups / unexpected structure)
- PowerShell-related tools behave inconsistently (execution/output issues)
Why this looks like a regression in core runtime (not model quality)
-
same model works via other providers
-
regression is strictly version-bound (1.3.12 → latest)
-
strongly suggests OpenCode-side change in:
- provider handling
- tool execution
- or message/tool-call flow
Likely culprit commits
Based on commit history after 1.3.12, these stand out:
Primary suspect
refactor(shell): use Effect ChildProcess for shell command executionrefactor(bash): use Effect ChildProcess for bash tool execution (#20496)
Reason:
- aligns directly with PowerShell/tool execution issues
- likely affects process spawning, env inheritance, stdio, exit handling
Secondary suspects (provider/message path)
refactor(prompt): use Provider service in effect layers (#20167)refactor: use Effect services instead of async facades in provider, ...refactor: add Effect-returning versions of MessageV2 functions (#20374)
Reason:
- regression is provider-specific (official Kimi only)
- these commits change provider resolution, prompt construction, and message handling
- could affect tool-call formatting or follow-up turns
Hypothesis
Most likely:
- shell/ChildProcess refactor introduced a regression in tool execution (esp. PowerShell)
Possibly combined with:
- provider/prompt refactor affecting official Kimi path, making the issue surface only there
Expected behavior
- tool calls should behave the same as in
1.3.12 - no provider-specific breakage for the same model
- PowerShell tools should execute reliably
Actual behavior
- tool-call failures / malformed behavior in latest version
- reproducible only on official Kimi provider
- PowerShell tool execution unreliable
If needed I can provide:
- exact error logs
- minimal prompt to reproduce
- tool definition used
Plugins
None related
OpenCode version
OpenCode version: 1.3.13
Steps to reproduce
Just use kimi from the kimi codingp lan and ask it to read some skills, about 70% of the time it fails.
It also is adding : in the start of the commands when trying to run powershell commands (making invalid),
mixing xml tags in the json requests to use tools
Screenshot and/or share link
Operating System
Windows 11
Activity
github-actions commentedon Apr 2, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
_No response_) — please provide the exact version you tested with (e.g.,1.3.13or1.3.14)Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue may overlap with existing issues. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
github-actions commentedon Apr 2, 2026
This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.
Feel free to open a new issue that follows our issue templates.
WanderWang commentedon Apr 2, 2026
I have the same issue when opencode upgrade from 1.3.9 to 1.3.13
ShibuyaCyana commentedon Apr 2, 2026
Yes, can confirm. Have to rollback to 1.3.12.
jiuheit commentedon Apr 2, 2026
I'm experiencing a regression between opencode-ai@1.3.12 and newer builds (1.3.13+) that appears to be specific to third-party model providers.
Repro matrix
→ ✅ works with all providers
→ ❌ tool-call errors with third-party providers
→ ✅ works with official providers (DeepSeek, etc.)
Specific findings
Third-party provider failure: Using WuWenXinQiong API (providing access to GLM-5, Qwen, etc.) results in tool-call failures
Official provider success: Using DeepSeek official provider works perfectly
Error pattern: - empty tool name injected between normal tool calls
Multiple models affected: GLM-5, Qwen, and other models via WuWenXinQiong API all fail
Same model works elsewhere: GLM-5 via official Kimi provider also fails (as reported in #20577)
Symptoms
Tool calls get aborted with "Tool execution aborted"
Invalid empty tool injected between normal tool calls
All tool functionality broken when using third-party providers
No issues when switching to official DeepSeek provider
Why this looks like a provider-handling regression
Same model architecture (GLM-5) fails via third-party but works via official provider
Regression is strictly version-bound (1.3.12 → 1.3.13+)
Suggests OpenCode-side change in provider handling or tool-call flow formatting
Likely culprit commits
Based on commit history after 1.3.12, these stand out:
Provider/prompt refactoring:
Tool execution changes:
Hypothesis
The provider refactoring in 1.3.13+ introduced changes that:
Affect how third-party providers format tool calls
Cause malformed tool-call flow with empty tool names
Only impact non-official provider paths
Expected behavior
Tool calls should work consistently across all providers
No provider-specific breakage for the same model capabilities
Third-party providers should function as in 1.3.12
Actual behavior
Tool-call failures when using third-party providers (WuWenXinQiong API)
Works fine with official providers (DeepSeek)
Regression reproducible across multiple models via third-party API
Environment
OpenCode version: 1.3.13
Platform: Windows 10 + WSL (Ubuntu)
Third-party provider: WuWenXinQiong API
Official provider tested: DeepSeek (works)
Steps to reproduce
Configure WuWenXinQiong API provider in OpenCode
Use any model (GLM-5, Qwen, etc.) via this provider
Attempt any tool call (bash, read, glob, etc.)
Observe tool-call failures with empty tool injection
Workaround
Switch to official providers (DeepSeek, etc.) - works
Downgrade to 1.3.12 - third-party providers work
SteveLTN commentedon Apr 5, 2026
I second this. After updating OpenCode to 1.3.15, when using Kimi K2.5 model with Kimi for Coding plan, tool calling has a high chance to fail.
It loops like this:
1.3.11 has the same behavior. But 1.3.10 is a bit different.
I didn't try even older version in 1.3.x. Went straight back to 1.2.27. It's calling the skills reliably.Update: also fails in 1.2.27.
Update again:
It seems the issue still appears on even older version (1.2.10).
SteveLTN commentedon Apr 6, 2026
Now I found that after rolling back to an older version, if it's followed by a configuration reset (I deleted ~/.local/share/opencode/ dir), it appears to be more stable at tool calling. I haven't tried extensively, but it seems to succeed at previously failing tasks.
Update: not really