Runtime tool_search conflicts with OpenAI Responses native tool_search

[liugddx]

Summary

Maka's runtime-defined deferred-tool connector is named tool_search. When a session uses an OpenAI Responses model (for example codex-subscription / gpt-5.6-sol), the current @ai-sdk/openai adapter treats that name as the provider-native openai.tool_search tool.

Maka returns a client tool result shaped like:

{"activated":["mcp__desktop_browser__browser_click"]}

The OpenAI Responses adapter validates native tool_search output as:

{"tools":[...]}

and rejects the Maka result before the next model request is sent.

Reproduction

1. Run the latest main desktop app on Windows.
2. Use the codex-subscription connection with gpt-5.6-sol.
3. Send a request that requires a deferred client capability, such as desktop browser tools.
4. The run fails immediately with:

Type validation failed: Value: {"kind":"json","value":{"activated":[...]}}
Error message:
[
  {
    "expected": "array",
    "code": "invalid_type",
    "path": ["tools"],
    "message": "Invalid input: expected array, received undefined"
  }
]

Evidence

The failure is produced while converting a local tool result in @ai-sdk/openai's Responses input converter. The runtime's connector is defined in packages/runtime/src/tool-availability.ts and uses the reserved provider name tool_search.

Expected behavior

Deferred tool activation should complete and the next model step should receive the activated Maka tools.

Proposed fix

Use a Maka-specific provider-visible connector name that cannot collide with OpenAI's reserved tool_search name, while preserving the internal activation semantics and updating history/replay, prompts, UI copy, and regression tests.

[liugddx]

Follow-up from the Windows reproduction: the first local fix only covered providerType=openai. The failing connection is codex-subscription (providerType=openai-codex), which also uses @ai-sdk/openai.responses(). The fix now gates the provider-safe alias on the resolved Responses adapter contract instead of the connection type. The regression test uses the real openai-codex/gpt-5.6-sol path, replays the existing {activated:[...]} tool result through the AI SDK converter, asserts the provider sees maka_tool_search, and asserts returned calls map back to the internal tool_search name.

[Lynskylate]

EN · Corroborating reproduction on Maka Desktop 0.2.0 (packaged release), macOS 25.4.0 arm64, openai-codex/gpt-5.6-luna — identical failure signature:

Failure: model_call_failed
Type validation failed: Value: {"kind":"json","value":{"activated":["mcp__desktop_browser__browser_navigate",...]}}
[{"expected":"array","code":"invalid_type","path":["tools"],"message":"Invalid input: expected array, received undefined"}]

Two additional observations from local provider-request artifacts that may help verification of #3958:

1. The session stays permanently broken. Every subsequent model call over history containing the poisoned tool_search tool-result re-fails at request-build time (1ms, retryable=false) — user retries, continue, any new message all fail. A history-compatibility/migration path (or fail-soft downgrade for legacy activated envelopes) would be worth considering alongside the rename.
2. Activated tools are never merged. Across four consecutive step-0 request artifacts, the top-level tools array stayed at the 33 pre-existing definitions — none of the 5 activated mcp__desktop_browser__* tools ever appeared, confirming the collision kills the whole activation → merge → next-request chain, not just one step.

Control: same tool_search call under a non-Responses provider (glm) returns the same {"activated":[...]} envelope and the turn continues normally.

Happy to attach the raw request artifacts if useful.

---

中文 · 在 Maka Desktop 0.2.0（packaged 发行版），macOS 25.4.0 arm64，openai-codex/gpt-5.6-luna 上复现，失败签名与描述完全一致：

Failure: model_call_failed
Type validation failed: Value: {"kind":"json","value":{"activated":["mcp__desktop_browser__browser_navigate",...]}}
[{"expected":"array","code":"invalid_type","path":["tools"],"message":"Invalid input: expected array, received undefined"}]

结合本地 provider-request 工件，补充两点观察，供 #3958 验证参考：

1. 会话会被永久污染。 只要历史里存在该 tool_search tool-result，后续每次模型调用都在请求构建阶段重新失败（1ms、retryable=false）——用户重试、发 continue、任意新消息全部失败。建议在重命名修复之外，同时考虑历史兼容/迁移（或对旧 activated 信封做 fail-soft 降级）。
2. 激活的工具从未被合并。 连续 4 个 step-0 请求工件中，顶层 tools 数组始终只有 33 个既有定义，被激活的 5 个 mcp__desktop_browser__* 工具一次都没出现 —— 说明该冲突破坏的是"激活 → 合并 → 下一次请求"整条链路，而不止单步。

对照组：非 Responses provider（glm）下同样的 tool_search 调用返回同样的 {"activated":[...]} 信封，turn 正常继续。

如需要可以附上原始请求工件。

---

Sanitized provider-request artifacts · 脱敏后的请求工件

EN · Below are the four consecutive step-0 provider-request artifacts (from the failing session, 10:57–11:06 local). Conversation text, file paths, usernames, and provider item IDs are redacted; structure, tool lists, and the tool_search tool-result are preserved verbatim.

#	request tools count	browser tools present	activated envelopes in history	prompt messages
1	33	0	1	85
2	33	0	1	84
3	33	0	1	81
4	33	0	1	82

Representative artifact (all four share the same shape):

• top-level keys: ["tools", "toolChoice", "prompt", "providerOptions", "includeRawChunks"]
• toolChoice: {"type":"auto"}
• providerOptions keys: ["openai"] (values scrubbed)
• request tools (33 built-ins; note: no mcp__desktop_browser__* despite activation):

["ArchiveRead", "AskUserQuestion", "Bash", "Edit", "ExploreAgent", "FormatJson", "Glob", "GoalClear", "GoalPause", "GoalResume", "GoalSet", "GoalStatus", "Grep", "MakaSettingsGet", "MakaSettingsUpdate", "memory_extract", "memory_remember", "Read", "ReadHistory", "request_sandbox_boundary", "ScheduledTask", "SearchHistory", "Skill", "SkillSearch", "StopBackgroundTask", "task_create", "task_get", "task_list", "task_update", "tool_search", "WebFetch", "Write", "WriteStdin"]

• the tool_search tool-result message in history, verbatim:

{
 "type": "tool-result",
 "toolCallId": "call_nnDEfozr8Q0BwaT4gByLV2J2",
 "toolName": "tool_search",
 "output": {
  "type": "json",
  "value": {
   "kind": "json",
   "value": {
    "activated": [
     "mcp__desktop_browser__browser_navigate",
     "mcp__desktop_browser__browser_type",
     "mcp__desktop_browser__browser_snapshot",
     "mcp__desktop_browser__browser_wait",
     "mcp__desktop_browser__browser_extract"
    ]
   }
  }
 }
}

中文 · 以下是失败会话中连续 4 个 step-0 provider-request 工件（本地时间 10:57–11:06）。已脱敏：对话正文、文件路径、用户名、provider itemId；保留结构、工具列表与 tool_search tool-result 原文。要点：4 个请求的 tools 均为 33 个内置工具、零 browser 工具，历史中各有 1 个 activated 信封 —— 佐证"激活结果从未合并、且每次请求都携带该信封重新触发校验失败"。