[Bug] MiMo v2.6 Pro frequently echoes <tool_call> in reasoning/Activity on 2.78.0 while tools execute normally (follow-up to #5724) #6689

English

Client or integration

Codex App on Windows, using MiMo Token Plan through a local OpenCodex proxy.

Summary

With OpenCodex 2.78.0 and mimo-v2.6-pro, serialized <tool_call><function=exec>…</parameter></function></tool_call> markup and JavaScript tool arguments frequently remain visible in the expanded reasoning / Activity area. They appear much less often in final answers and delivery reports.

Tool execution usually continues normally and tasks can complete. The screenshots show command execution, file reading/editing, and subsequent task progress alongside the visible markup. The observed problem is frequent visible tool-call echoes; no widespread execution failure attributable to these echoes has been observed.

Related: #5724, #5725, #5674. Version 2.64.0 in #5724 is the affected version reported there, rather than the version containing the fix. #5725 describes fixes merged into dev after the 2.64.0 release, including missing </function> and a newline after the function header. This report concerns remaining behavior on 2.78.0; whether it is a regression is not established.

Expected: hide markup that can reliably be identified as a duplicate of an actual structured tool call, while preserving ordinary quotations/examples and executing the actual call normally.

Reproduction

1. Configure MiMo Token Plan with openai-chat and select mimo/mimo-v2.6-pro.
2. Perform normal multi-step file reading, searching, checking, or editing tasks in Codex App.
3. Expand reasoning / Activity. Complete tool-call markup, exec JavaScript, and closing tags frequently appear immediately after narrative prose.
4. The same task still shows tool execution activity and continues to deliver results.

The original tasks involve a private project, so commands, business context, paths, and filenames are withheld. Attachments use opaque pixel masks; the remaining pixels were not regenerated or rewritten. Frequency is a qualitative user observation, not a measured percentage. One simple read-only subagent attempt did not reproduce the echo, so this is not claimed to happen on every turn.

Environment

• OpenCodex: @bitkyc08/opencodex 2.78.0. Verified in package.json in the installation used by the running service; the service launches src/cli/index.ts from that installation. This is not based solely on the latest-version update cache.
• Codex App: 26.930.61225.
• Codex runtime reported in the service log: 0.160.1.
• OS: Windows; exact edition/build was not separately verified.
• Provider/model: MiMo Token Plan / mimo-v2.6-pro.
• Adapter: openai-chat.
• Base URL: https://token-plan-cn.xiaomimimo.com/v1.
• Authentication: API key.
• No per-model modelAdapters override.

Investigation: inline markup may bypass the bare-block reader

This is a locally verified parser behavior and a possible lead, not a confirmed end-to-end root cause.

In the installed package, src/adapters/openai-chat/serialized-tool-call-content.ts checks OPEN_TAG inside the context.lineStart branch of splitAtPossibleSerializedToolCall(). Its comments intentionally preserve markup in prose. Several screenshot examples and copied replies place the markup immediately after narrative text, with this shape:

[Private task description redacted]. <tool_call><function=exec>const cmds = [
…
</parameter></function></tool_call>

The following minimal check was run against the installed 2.78.0 package. It calls only the parser; it does not send a model request or execute a tool:

import { splitAtPossibleSerializedToolCall as split }
  from "./src/adapters/openai-chat/serialized-tool-call-content.ts";

const block =
  "<tool_call><function=exec>text(1);</parameter></function></tool_call>";

for (const [name, input] of [
  ["line-start", block],
  ["inline-after-prose", "检查完成。 " + block],
]) {
  console.log({ name, hasOpenTag: split(input, undefined, true).hasOpenTag });
}

The Chinese prefix above is nonsensitive test prose meaning “Check complete.” Actual output:

{"name":"line-start","hasOpenTag":true}
{"name":"inline-after-prose","hasOpenTag":false}

This establishes the reader's line-start restriction only. No corresponding raw provider SSE was captured, so the UI text cannot yet be attributed conclusively to content, reasoning_content, or a later bridge. Byte-for-byte agreement between each echo and the structured arguments in the same response has also not been verified.

Could maintainers confirm:

• Whether an inline MiMo exec echo following narrative prose should also be suppressed when a matching structured call exists?
• Whether suppression covers the event path carrying these echoes in the reasoning / Activity UI?
• Which supported redacted structural diagnostics would distinguish these cases without sharing private tool arguments?

Logs or error output

No corresponding HTTP/tool failure was shown to the user. Recently inspected MiMo usage entries returned HTTP 200, but HTTP 200 alone is not proof that every tool succeeded. Raw provider SSE is not included.

Screenshots and supporting files

Opaque masks remove usernames, local paths, project filenames, command strings, and private business content. Tool markup, generic JavaScript scaffolding, and tool activity rows remain visible.

1. Echo in Activity alongside command execution and image-viewing activity:

2. Multi-command exec echo followed by file editing/reading/command activity and a report region:

3. Repeated echoes in the same Activity area, with actual tool activity rows:

Redacted configuration

{
  "providers": {
    "mimo": {
      "adapter": "openai-chat",
      "baseUrl": "https://token-plan-cn.xiaomimimo.com/v1",
      "authMode": "key",
      "apiKey": "<REDACTED>",
      "defaultModel": "mimo-v2.6-pro"
    }
  },
  "webSearchSidecar": { "streamRoutedModelOutput": true },
  "websockets": false
}

Relevant fields only, not the full configuration. Whether the sidecar option applies to the screenshot requests is unconfirmed.

Checks

• Searched existing issues and documentation; related reports/fixes are linked above.
• Removed secrets, usernames, private paths, and project content. Original screenshots, configuration files, and session logs were not uploaded.

中文说明

Client or integration

Codex App（Windows），通过本机 OpenCodex 代理使用 Mimo Token Plan。

Summary

在 OpenCodex 2.78.0 使用 mimo-v2.6-pro 时，<tool_call><function=exec>…</parameter></function></tool_call> 和 JavaScript 工具参数仍以普通文字高频出现在 Codex 展开的推理／Activity 区域。最终结论和交付报告里较少出现。

工具调用通常仍能正常执行，任务可以继续完成。截图里可见“运行了命令”“编辑了文件/读取文件”等真实工具活动行，以及随后交付的报告。本报告主要针对可见回显，未观察到由此导致的普遍工具执行失败。

相关：#5724、#5725、#5674。#5724 的 2.64.0 是报告问题时的版本；#5725 说明主要修复在 2.64.0 发布后合入 dev，并补充缺少 </function> / header 后换行的变体。本次是后续 2.78.0 仍出现的残留情况，尚不能确定是否为回归。

预期：能够可靠确认与真实结构化工具调用重复的标记应被隐藏，工具照常执行；普通引用和示例仍应保留。

Reproduction

1. Mimo 提供商使用下述 Token Plan 地址及 openai-chat，选择 mimo/mimo-v2.6-pro。
2. 在 Codex App 中执行正常的多步文件读取、搜索、检查或编辑任务。
3. 展开推理／Activity；经常看到正文后直接追加完整 <tool_call> 标记、exec JavaScript、结束标记。
4. 同一任务仍显示工具执行活动并继续交付结果。

实际任务涉及私有项目，因此未公开原始命令、业务说明、路径或文件名。附件仅做不透明遮蔽，未重新生成或改写剩余像素。用户观察为高频发生，未提供量化比例；一次简单的只读子代理尝试没有复现回显，所以不声称每个任务必现。

Version

@bitkyc08/opencodex 2.78.0。已检查当前服务所使用安装目录的 package.json 为 2.78.0，服务进程从该安装目录的 src/cli/index.ts 启动。
Codex App 版本：26.930.61225；服务日志中的 Codex runtime：0.160.1。
没有仅凭“latest_version”更新检查缓存判断运行版本。

Operating system

Windows（本次未另行确认具体 Windows edition/build）。

Provider and model

Mimo Token Plan / mimo-v2.6-pro

• adapter: openai-chat
• baseUrl: https://token-plan-cn.xiaomimimo.com/v1
• authMode: key
• 模型无 modelAdapters 覆盖项。

Investigation: inline markup may bypass the bare-block reader

这是本地源码与一个最小解析器检查得到的线索，并非已确认的完整根因。

安装包内 src/adapters/openai-chat/serialized-tool-call-content.ts 的 splitAtPossibleSerializedToolCall() 仅在 context.lineStart 内检查 OPEN_TAG，注释明确保留 prose 中的标记。截图及复制出的回复中，多个标记紧接在叙述句末，如：

[私有任务说明已删去]。 <tool_call><function=exec>const cmds = [
…
</parameter></function></tool_call>

在本机 2.78.0 安装包下执行以下最小检查（仅调用解析器，不发送模型请求，不执行工具）：

import { splitAtPossibleSerializedToolCall as split }
  from "./src/adapters/openai-chat/serialized-tool-call-content.ts";

const block =
  "<tool_call><function=exec>text(1);</parameter></function></tool_call>";

for (const [name, input] of [
  ["line-start", block],
  ["inline-after-prose", "检查完成。 " + block],
]) {
  console.log({ name, hasOpenTag: split(input, undefined, true).hasOpenTag });
}

实际结果：

{"name":"line-start","hasOpenTag":true}
{"name":"inline-after-prose","hasOpenTag":false}

这个结果仅证明 reader 的行首限制；未捕获对应原始 SSE，所以不能确认 UI 中每段文字来源于 content、reasoning_content 或后续桥接，也没有证明回显正文与同一响应的结构化参数字节完全一致。希望维护者确认：

• 正文后直接追加的 MiMo exec 回显是否应在存在匹配的结构化调用时也被清理？
• 清理逻辑是否覆盖 UI 推理／Activity 中承载这些标记的事件通路？
• 若需要更多信息，哪些受支持的脱敏结构诊断能区分该情况，而无需分享私有工具参数？

Logs or error output

未出现对应 HTTP/tool failure 的用户可见报错。已读取的近期 Mimo usage 条目为 HTTP 200；HTTP 200 本身不作为每个工具成功的充分证明。本报告没有原始 provider SSE。

Screenshots and supporting files

黑色区域遮蔽用户名、本地路径、项目文件名、命令字符串及业务内容；保留工具标记、通用 JavaScript 结构和工具执行活动行。

1. Activity 中标记与命令执行、图像查看记录并存：
   

2. 多命令 exec 回显，后面仍显示文件编辑／读取／命令活动及报告区域：
   

3. 同一 Activity 中多次回显，仍有真实工具活动行：
   

Redacted configuration

{
  "providers": {
    "mimo": {
      "adapter": "openai-chat",
      "baseUrl": "https://token-plan-cn.xiaomimimo.com/v1",
      "authMode": "key",
      "apiKey": "<REDACTED>",
      "defaultModel": "mimo-v2.6-pro"
    }
  },
  "webSearchSidecar": { "streamRoutedModelOutput": true },
  "websockets": false
}

这是相关字段节选，不是完整配置；未确认上述 sidecar 选项是否与截图请求有关。

Checks

• 已搜索既有 issue 和文档，关联 使用mimo时候会显示<tool_call></tool_call>的信息 #5724 / fix(openai-chat): read MiMo tool-call echoes without </function> or with a header newline #5725。
• 已遮蔽密钥、用户名、私有路径和项目内容；未上传原始截图、配置文件或会话日志。