[Bug] v0.2.5 + Codex 0.154：Chat 回退丢失 namespace 内 custom exec，导致 functions__exec unsupported

问题概述

在 Sub2API v0.2.5（官方最新版本） 中，把 Codex 的 GPT 模型名映射到 DeepSeek，并将账号协议设为 Chat Completions 后，普通对话可以工作，但 Codex 无法调用本地终端。

模型会反复返回：

function_call name="functions__exec"
function_call_output "unsupported call: functions__exec"

浏览器/MCP 等普通 function 工具可以调用。Windows 本地 sandbox 与 command runner 已确认正常，因此不像是目录权限或本地执行环境故障。

环境

• Sub2API：v0.2.5，官方发布版，无本地代码修改
• 客户端：Codex Desktop / CLI 0.154.0-alpha.6.2
• 系统：Windows 10 19045
• 入站：Responses API（stream）
• 上游账号：DeepSeek，API 协议选择 Chat Completions
• 模型映射：gpt-5.6-luna/sol/terra、gpt-6-astra → deepseek-flash

复现步骤

1. 在 Sub2API 创建 DeepSeek API Key 账号，协议选择 Chat Completions。
2. 将 Codex 使用的 GPT 模型映射到 DeepSeek 模型。
3. 在 Codex 0.154 中打开一个包含本地项目路径的任务。
4. 要求 Codex 读取项目文件或运行终端命令。
5. 模型尝试调用 functions__exec，客户端返回 unsupported call: functions__exec，命令没有执行。

现场证据

同一会话的 rollout 中连续出现 6 次：

{"type":"function_call","name":"functions__exec","call_id":"..."}
{"type":"function_call_output","output":"unsupported call: functions__exec"}

本地执行环境排查结果：

• codex.exe sandbox 进程正常运行；
• codex-command-runner-0.154.0-alpha.6.2.exe 进程正常运行；
• runner 已被正确复用并成功启动；
• 此时没有 CreateProcessWithLogonW 或 ACL 启动失败。

因此，UI 中看到的“无终端/无文件读取能力”是工具协议没有正确还原后的结果，并非项目目录未授权。

疑似原因

当前桥接代码对 namespace 子工具只接受 type == "function"：

• NamespaceToolNames 中会跳过 child.Type != "function"；
• namespaceChildrenToChatTools 中也会跳过 child.Type != "function"。

如果 Codex 0.154 把 exec 作为 namespace functions 下的 custom 子工具声明，那么它会在 Responses → Chat 转换时被静默丢弃，也不会进入回程 identity map。DeepSeek 随后生成扁平名 functions__exec，Sub2API 将其作为普通 function_call 返回，Codex 因找不到对应工具而拒绝。

这是基于当前源码和 rollout 的推断；建议在服务端记录一份脱敏后的原始 tools 声明确认。

期望行为

• namespace 内的 custom 子工具也能被转换为 Chat function；
• 回程时保留并恢复原始工具身份与类型，输出 Codex 可识别的 custom_tool_call，不要把扁平名 functions__exec 原样返回；
• 增加“namespace 中同时含 custom exec 与 function wait”的回归测试；
• 不回退此前对顶层 custom exec 和 tool discovery 的修复。

与已有 Issue 的区别

• #5883 处理的是 Codex 0.14x 的**顶层 custom exec**被 DeepSeek 类比为 functions__exec 的别名还原问题；
• #6584 处理的是 tool_search 发现的工具在 Chat fallback 中丢失；
• 本问题发生在 v0.2.5 + Codex 0.154，疑似是新版请求把 custom exec 放进 namespace 后，被现有 child.Type != "function" 判断过滤。

如果原始请求证实 exec 仍是顶层 custom，则说明 #5883 的修复在 v0.2.5 的另一条 fallback 路径上发生了回归，同样需要检查工具 identity map 在完整转发链路中是否保留。