fix: toWireToolName 取错了别名表来源，且作用方向与 CLI 相反（messages 该改没改、tools 声明不该改却改了） #37

Activity

1. xelr233

   added a commit that references this issue on Sep 14, 2026

   fix: 工具名重写对齐 CLI —— 只在 messages 里改，且只改一项

   ...

   383aed8
2. xelr233 commented on Sep 14, 2026

   

   xelr233

   on Sep 14, 2026

   ContributorAuthor

   More actions

   结论：这张别名表应该整体删掉，toWireToolName 改回恒等

   补充 #37 里没拿到的那块拼图 —— tool_search 是 CLI 自己退役的名字，而且不可见：

   function createSearchToolsTool(e){
     return { ...,
       schema: { name: nw,                    // nw = "search_tools"，当前名
                 label: "SEARCH TOOLS", ... } }
   }
   
   function createRetiredToolSearchTool(e){
     const t = createSearchToolsTool(e);
     return { ...t,
       visible: () => false,                  // ← 不进面向模型的 catalog
       schema: { ...t.schema,
         name: rw,                            // rw = "tool_search"，退役名
         description: \`Retired: use \${nw} instead. Calls to the \${rw} NAME are
                       routed to \${nw} by the runner automatically. ...\` } }
   }

   它确实从不上网：

   function createToolRunner(e){
     const t = e.tools ?? gg;
     const n = createSearchToolsTool(...);        // search_tools
     const r = createRetiredToolSearchTool(...);  // tool_search（visible:false）
     const o = () => [...t, n, r];                // allTools：只为 runner 按名查找
     const s = createToolCatalog({ tools: o, ... });
   }
   
   const o = t => { const n = dedupeTools(e.tools());
                    const r = t.includeHidden ? n : n.filter(isVisible); ... };
   function isVisible(e){ return e.visible?.() !== false }

   调用方那边，发请求用的那次 getSchemas 不带 includeHidden，只有本地查 schema 才开：

   const T = r.toolRunner.getSchemas({ mode: e });                               // → 声明给上游
   const M = t => (P ??= r.toolRunner.getSchemas({ mode: e, includeHidden: true }))
                    .find(e => e.name === t);                                    // → 纯本地查找

   所以 params.tools 里永远没有 tool_search。四个函数排在一起就完全自洽了：

   函数	对名字做什么	为什么
   toWireTools	原样 {name,description,input_schema}	声明列表里只有当前名，无需归一化
   toWireMessages	tool-call 与 tool-result 都用 toWireToolName，map 存改后的名字	重放旧会话时历史里可能有退役名
   resolveToolNameAlias（ow 表）	改的是执行目标，回一句给模型看的 Repair note，还补 defaults	模型喊了退役名 → 本地按新名字跑

   toWireToolName 不是「工具重命名设施」，而是「把自家 catalog 里那一个退役名字的历史归一化」。 它成立的前提是：CLI 自己退役过工具名，而且可能在重放用旧名字录下来的会话。

   ---

   proxy 没有这个前提

   • params.tools 来自下游客户端，proxy 没有 catalog、没有退役名；
   • 请求里出现的每个名字，对 proxy 来说都是「当前名」——没有东西需要归一化；
   • 如果客户端真声明了一个叫 tool_search 的工具，把它改掉是纯粹的错。

   而且现在的改法（只改声明、不改消息）连内部自洽都做不到：CLI 是「声明用当前名 + 消息也用当前名」，现在是「声明改名 + 消息不改名」，两头都不对。

   ---

   建议改法

   ① 默认（推荐）：删掉整张表。

   // 删除 TOOL_NAME_ALIASES / WIRE_TOOL_ALIASES 与 toWireToolName，三处调用点退回原名
   body.params.tools = (tools || []).map(t => ({
     name: t.function?.name || t.name || '',        // 原样
     description: ..., input_schema: ...,
   }));
   toolNameMap[tc.id] = tc.function?.name || '';    // 原样
   parts.push({ type:'tool-call', toolCallId: tc.id,
                toolName: tc.function?.name || '', input: ... });
   toolName: toolNameMap[msg.tool_call_id] || msg.name || ''   // 原样

   声明与消息天然一致，#36 的症状直接消失，也不需要任何「改回去」的对称逻辑。

   ⚠️ 只保留一项别名（tool_search→search_tools）并不能解决问题：一旦下游客户端恰好声明了一个名为 tool_search 的工具，就会复现同一个 bug —— 声明是 tool_search、消息是 search_tools。要么两端都不改，要么两端一起改；而「两端一起改」会把客户端自己的 API 面改写掉，所以只剩「都不改」。

   ② 若确实要支持「重放真实 CLI 旧会话」：那也不该是出站改写，而应是入站归一化 + 显式开关（只有下游本身就是 CC CLI 形态的 harness 时才开），并且连 defaults 一起补，与 resolveToolNameAlias 同语义。这样声明与消息仍然一致。唯独不要做成「上行改、下行不改」。

   ---

   关于 #36

   症状描述是对的（声明与消息不一致 → 下游派发不了），但有两处需要更正：

   1. 「cli 也不会强制改名」—— 对 bash_output 成立，推广不成立。CLI 确实会改 tool_search，只是只改这一项、只在 messages 里改；
   2. 「本质是兼容旧工具名」—— 比这更彻底：那个旧名字 CLI 自己都不声明（visible:()=>false），纯粹是重放历史用的。

   至于「在原工具名上加几个随机字符（bash_output-cmdc-m）」这个提议，方向是反的：

   • 下游必须能认出回传的工具名才能派发，加后缀直接破坏契约；
   • 工具名是客户端自己的 API 面，不是指纹维度。真实 CLI 每个用户发出的 params.tools 名字完全一样（shell_output/read_file/edit_file…），「多账号工具名相同」本来就是常态，加随机后缀反而制造了一个所有真实 CLI 都没有的偏差；
   • CLI 的 toWireTools 是原样下发。

   ---

   复验

   curl -sSL "$(curl -sS https://registry.npmjs.org/command-code/latest \
     | grep -o 'https://registry.npmjs.org/command-code/-/command-code-[^"]*\.tgz' | head -1)" \
     | tar xzO package/dist/cli.mjs > cli.mjs
   grep -o 'function toWireToolName([^}]*}'          cli.mjs   # e===rw?nw:e
   grep -o 'function createRetiredToolSearchTool([^}]*}}' cli.mjs  # visible:()=>false
   grep -o 'function toWireTools([^}]*}'             cli.mjs   # 无别名

   （我这边已按 ① 改完并在真机 mock 上验证：声明与消息现在都原样透传；新增 4 条 wire 契约断言覆盖「声明不改名 / tool_search 在消息里也不改名 / tool-result 与 tool-call 名字一致」。）
3. xelr233

   added a commit that references this issue on Sep 14, 2026

   fix: 工具名一个都不重命名 —— 删除 toWireToolName（383aed8 的收尾）

   ...

   3cefa6b
4. jinyu2022 commented on Sep 15, 2026

   

   jinyu2022

   on Sep 15, 2026

   Contributor

   More actions

   我提议的增加随机字符，主要是为了方便回传。最初我只是简单地在回传逻辑中增加了一张反向映射表，但很快发现，如果直接进行新旧值映射，下游传入新值时，也可能被错误地映射回旧值。
   因此，还需要额外增加一个字段，用于标识下游传入的是否为新的工具名；如果是新工具名，则不再进行映射。这样一来，整体实现的代码量就会增加不少，不如直接自定义一个随机的下游不可能传的后缀。

   当然我也同意直接删去映射，直接请求。

   特征方面近乎无解，最好是让下游别用这几个工具名：

   1. 上游可以检测到调用参数不一致，而且旧工具还会有提示词注入，这都和cli表现不一致
   2. 加后缀或者修改成随机字符也是明显特征
5. MAXeaglet commented on Oct 9, 2026

   

   MAXeaglet

   on Oct 9, 2026

   Owner

   More actions

   已随 PR #58 合入修复：\ oWireToolName\ 单向别名表已被彻底废除，所有工具名在 wire 层面全程原样透传，声明与消息保持同名一致。
6. MAXeaglet

   closed this as completedon Oct 9, 2026