Skip to content

Regression after 1.3.12: tool-call failures (PowerShell + malformed JSON behavior) on official Kimi provider #20577

Closed as not planned

Description

@fernandodamaso

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 execution
  • refactor(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

Image Image

Operating System

Windows 11

Terminal

Activity

  1. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Apr 2, 2026
  2. github-actions commented on Apr 2, 2026

    @github-actions
    Contributor

    This issue doesn't fully meet our contributing guidelines.

    What needs to be fixed:

    • OpenCode version is empty (_No response_) — please provide the exact version you tested with (e.g., 1.3.13 or 1.3.14)
    • Operating System is empty — required for bug reports
    • Steps to reproduce is empty — the repro matrix in the description is helpful context, but please fill in the formal steps field with a minimal, concrete reproduction sequence
    • The description reads as AI-generated (detailed commit blame analysis without actual error logs or a minimal repro) — please replace with your direct observations, actual error output, and a concrete reproduction scenario

    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.

  3. github-actions commented on Apr 2, 2026

    @github-actions
    Contributor

    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.

  4. WanderWang commented on Apr 2, 2026

    @WanderWang

    I have the same issue when opencode upgrade from 1.3.9 to 1.3.13

  5. ShibuyaCyana commented on Apr 2, 2026

    @ShibuyaCyana

    Yes, can confirm. Have to rollback to 1.3.12.

  6. jiuheit commented on Apr 2, 2026

    @jiuheit

    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

  7. SteveLTN commented on Apr 5, 2026

    @SteveLTN

    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:

    → Skill ":agent-browser"
    Skill ":agent-browser" not found. Available skills: agent-browser, apple-reminders, apple-notes
    → Skill ":agent-browser"
    Skill ":agent-browser" not found. Available skills: agent-browser, apple-reminders, apple-notes
    → Skill ":agent-browser"
    Skill ":agent-browser" not found. Available skills: agent-browser, apple-reminders, apple-notes
    → Skill ":agent-browser"
    Skill ":agent-browser" not found. Available skills: agent-browser, apple-reminders, apple-notes
    → Skill ":agent-browser"
    Skill ":agent-browser" not found. Available skills: agent-browser, apple-reminders, apple-notes
    → Skill ":agent-browser"
    Skill ":agent-browser" not found. Available skills: agent-browser, apple-reminders, apple-notes
    → Skill ":agent-browser"
    Skill ":agent-browser" not found. Available skills: agent-browser, apple-reminders, apple-notes
    → Skill ":agent-browser"
    Skill ":agent-browser" not found. Available skills: agent-browser, apple-reminders, apple-notes
    

    1.3.11 has the same behavior. But 1.3.10 is a bit different.

    → Skill ":/Users/ltn/ai-workspace/.agents/skills/agent-browser/SKILL.md{"
    Skill ":/Users/ltn/ai-workspace/.agents/skills/agent-browser/SKILL.md{" not found. Available skills: agent-browser, apple-notes, apple-reminders
    → Skill ":/Users/ltn/ai-workspace/renovation/.opencode/skill/agent-browser/SKILL.md{"
    Skill ":/Users/ltn/ai-workspace/renovation/.opencode/skill/agent-browser/SKILL.md{" not found. Available skills: agent-browser, apple-notes, apple-reminders
    

    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.

    → Skill ":browser"
    Error: Skill ":browser" not found. Available skills: agent-browser, apple-notes, apple-reminders
    → Skill ":browser"
    Error: Skill ":browser" not found. Available skills: agent-browser, apple-notes, apple-reminders
    

    Update again:

    It seems the issue still appears on even older version (1.2.10).

  8. SteveLTN commented on Apr 6, 2026

    @SteveLTN

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingcoreAnything pertaining to core functionality of the application (opencode server stuff)

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions