[Bug] No Tools get Called

[KodokSatuw]

版本 / Version

latest

部署方式 / Deployment

自建服务器 / Self-hosted

问题描述 / What happened?

AI Only Writing Code without Calling Tools, so when ai give response no file get write or rewrite

复现步骤 / Steps to reproduce

Kilo Code and Opencode.

日志 / Logs

模型 / Model

GPT 5.4 xHigh

环境 / Environment

docker

[f0rSee]

same issue in codex

[sugus-d]

same issue

[dwgx]

Which model and which tool failed to be called?

At the time of this reply, v2.0.97 had already merged the Cascade reuse work from #181. Please retest with a Claude-family model such as claude-sonnet-4.6 and attach the nearby debug logs.

For a useful reproduction, I need:

• client name and version,
• exact model,
• request route,
• declared tool names and schema count,
• the relevant Probe[...] and tool-routing log lines.

Without those, this issue can only be treated as a broad "tool not called" bucket, because the root cause can be client stripping, schema size, model behavior, prompt-emulation limits, or native-bridge gating.

[dwgx]

Update from v2.0.124:

Native bridge visibility improved, but this still should not be treated as a production-wide fix for every "no tools called" report.

What changed:

• Cascade search_web trajectory steps can now be decoded for trace/debugging.
• Cascade read_url_content trajectory steps can now be decoded for trace/debugging.
• The native bridge smoke script can explicitly run WebSearch/WebFetch scenarios, but the default all smoke still excludes those lab-only web tools.

Current boundary:

• Production-mature native bridge scope remains the Bash/run_command family.
• Read/Grep/Glob/WebSearch/WebFetch are protocol-lab surfaces unless explicitly gated by API key, account, model, and tool allowlist.
• WINDSURFAPI_NATIVE_TOOL_BRIDGE=all_mapped is not a general fix. It is only useful for narrow, controlled reproductions.

For this issue, please attach Probe[...], ToolRoute[...], the client name, exact model, and the tool names/schema count.

[xy-guli]

更新：此类“没有调用任何工具”现在有一条新的尝试路径。

如果您的客户端仅声明可映射工具，例如Read/Bash/Grep/Glob/WebSearch/WebFetch，可以尝试： WINDSURFAPI_NATIVE_TOOL_BRIDGE=all_mapped

这个模式不会再把这些工具塞进提示前言，而是走Cascade原生桥。刚在VPS上用claude-4.5-haiku + Read做了烟测，返回了标准的OpenAI tool_calls。

注意：

• 默认还是关闭，原因见[Bug]Claude模型自动启用原生工具桥导致工具调用永久卡死 #124：很多客户端的Read/Bash是“本地工具”，而Cascade DEFAULT planner可能会尝试在工作空间执行。
• 如果工具列表里混了MCP/custom/update_plan/apply_patch，这个模式不会开启，仍走仿真。
• 如果复现，请贴Probe[...] tools=N、native bridge ON或emulateTools=true那几行日志，以及工具列表。

没有很理解大佬

[dwgx]

@xy-guli 简单说：不要把它理解成“打开一个开关，所有工具都会好了”。

现在最稳的用法是：只拿一个测试 key / 一个测试模型，先灰度 Bash 这类命令工具；文件读取、搜索、glob 这些还在逆协议阶段，暂时不要全量开。上面那条我已经改成更具体的排查步骤了。

[dwgx]

Update from v2.0.139:

Current position:

• The default production tool path is still prompt/tool emulation.
• Native bridge means remote Windsurf workspace execution, not local IDE/MCP/client tool execution.
• The production-mature native bridge scope remains Bash / shell_command / run_command.
• Read/Grep/Glob/WebSearch/WebFetch are still trace/POC surfaces and should not be enabled as the default production fix.

If this issue still reproduces, please provide the client name/version, exact model, request route, tools schema count, expected tool name, and the nearby Probe[...] / ToolRoute[...] logs. That is the only reliable way to separate model behavior from client/schema translation or native-bridge routing.

[dwgx]

Update from v2.0.141:

This stays open for concrete "no tools called" reproductions. The proxy now logs enough routing context to distinguish several different cases:

• tool_choice=none or forced tool not declared,
• server-side tools stripped by /v1/messages or /v1/responses,
• tool preamble compacted because the client sent a large tool catalog,
• native bridge disabled by gate / allowlist / all_mapped mismatch,
• model emitted narration but no parseable tool_call.

Please attach ToolRoute[...], Probe[...], client/model/route, and the tool names/schema count for the next failure. Do not treat WINDSURFAPI_NATIVE_TOOL_BRIDGE=all_mapped as a general fix; default native bridge scope remains the Bash/run_command family only.

[dwgx]

Thanks for the reports and confirmations.

Status update: I am keeping this issue open as a reproduction bucket instead of marking it fixed from a single route change.

Current evidence:

• The latest builds add ToolRoute[...] and BridgeResult[...] diagnostics so we can tell whether the request lost tools before reaching the model, fell back to prompt emulation, missed a native-bridge gate, or the model simply narrated instead of emitting a parseable tool call.
• Native bridge is not a universal "make all tools work" switch. The production-mature native scope remains the Bash/run_command family only.
• Read/Grep/Glob/WebSearch/WebFetch remain protocol-lab surfaces unless explicitly gated by API key/account/model/tool.

For the next reproduction, please attach:

• client name/version (Kilo Code, opencode, Codex, etc.),
• exact model,
• request route (/v1/chat/completions, /v1/messages, or /v1/responses),
• tool names and schema count,
• the nearby Probe[...], ToolRoute[...], and BridgeResult[...] log lines.

That will let me separate a client/schema problem from a model behavior problem or a native-bridge routing problem.