[Bug]接入Claude Code后触发联网搜索时会丢失用户输入

[bvooscale]

版本 / Version

v2.0.96

部署方式 / Deployment

自建服务器 / Self-hosted

问题描述 / What happened?

接入Claude Code后触发联网搜索时会丢失用户输入

复现步骤 / Steps to reproduce

Claude Code

日志 / Logs

模型 / Model

No response

环境 / Environment

No response

[bvooscale]

模型直接无视我的第二次提问，而是回答重复第一次提问。实测使用接入openwebui触发搜索时也会出现这个问题。

[dwgx]

Please attach LOG_LEVEL=debug logs for the failing request, especially the nearby Probe[...], ToolRoute[...], BridgeResult[...], and Cascade trajectory lines.

Earlier builds did not have enough evidence to distinguish WebSearch/WebFetch result handling from upstream context behavior. That has changed: v2.0.144 later identified and fixed one proxy-side WebFetch handling bug in the lab-gated native path. Completed read_url_content.web_document payloads are no longer surfaced as dead client tool calls when Cascade has already produced a final answer.

This issue should still stay open until the original Claude Code/OpenWebUI scenario is retested on a deployed v2.0.144+ instance.

[dwgx]

Thanks for the report. Updated status after the later protocol work:

The original symptom can happen in more than one path, so I no longer want to describe it as simply "upstream context stitching".

What is now known:

• Claude Code / OpenWebUI web flows may enter either WebSearch-style search or WebFetch/read-url handling.
• The native WebSearch/WebFetch protocol is still gated and not a default production path.
• In v2.0.144, one concrete proxy-side bug was fixed: when the language server returned a completed read_url_content.web_document and Cascade already had final assistant text, WindsurfAPI could incorrectly surface the completed step as a pending client tool call. That could drop the useful final answer and look like the original prompt was lost.

Next useful check:

• retest the same Claude Code/OpenWebUI flow on v2.0.144+ after deployment,
• attach the request route, model, Probe[...], ToolRoute[...], BridgeResult[...], and any redacted webFetchTrace.state summary.

This issue remains open until that real client flow is verified.

[dwgx]

Update from v2.0.124, revised after the later v2.0.144 trace work:

At this point the important boundary is:

• WebSearch/WebFetch are still not default production native-bridge tools.
• Direct WebSearch investigation has a confirmed API path.
• A direct WebFetch/read-url API endpoint is still not confirmed; the observed official path is LS requested interaction plus HandleCascadeUserInteraction, followed by a later trajectory step.

Later v2.0.144 evidence showed that a completed read_url_content.web_document can arrive in the same branch as a requested-interaction echo. The proxy now classifies that as a completed document first and preserves Cascade's final assistant text instead of returning a dead tool proposal.

So the old "we only have partial web oneof visibility" statement is stale. The remaining caution is production scope: this fix is for the lab-gated native WebFetch path and does not mean WebSearch/WebFetch should be enabled by default for all production traffic.

[dwgx]

Update after v2.0.144:

The earlier v2.0.141 VPS canary was blocked by ls_capacity:memory_guard, so it did not prove WebFetch success or failure.

A later isolated-memory lab run did produce the missing evidence:

• the LS permission flow can return a real completed read_url_content.web_document,
• the completed document may appear together with a requested-interaction echo,
• the proxy was incorrectly treating that completed native result as a pending client tool proposal in some cases,
• v2.0.144 fixes that handling and also fixes proto-trace classification so completed WebFetch documents win over pending-permission echoes.

This is a real proxy-side fix for the lab-gated native WebFetch path. It is still not a default production enablement decision for WebSearch/WebFetch.

Next step for this issue: retest the original Claude Code/OpenWebUI web-search/web-fetch workflow on a deployed v2.0.144+ instance and attach redacted Probe[...], ToolRoute[...], BridgeResult[...], and webFetchTrace.state logs if it still loses the user input.

[dwgx]

更新：v2.0.144 已发布，包含一个和本 issue 直接相关的修复。

修复范围很具体：在 lab-gated native WebFetch 路径里，如果 Windsurf LS 已经返回完成的 read_url_content.web_document，并且 Cascade 已经产出最终回答，WindsurfAPI 现在不会再把这个已完成步骤错误地作为“待客户端执行的 tool_call”返回。旧行为可能导致客户端看到 content=null / tool proposal，表现得像联网后丢失了原始用户输入。

边界也说明清楚：这不是把 WebSearch/WebFetch 默认开放为生产 native bridge。WebFetch 仍需要明确 gate；v2.0.144 修的是 completed WebFetch document handling。

请在部署到 v2.0.144+ 后复测原来的 Claude Code / OpenWebUI 联网流程。如果仍复现，请贴这些日志：

• 请求 route 和模型名
• Probe[...]
• ToolRoute[...]
• BridgeResult[...]
• 如果开了 proto trace，再附 webFetchTrace.state 摘要

有这些信息后可以继续区分是 WebSearch 路径、WebFetch/read-url 路径，还是客户端渲染/上下文拼接问题。