修复 Custom Responses 新任务缺失 Web Search / Restore Web Search for custom Responses tasks

[Yuimi-chaya]

中文

问题与影响

Codex App 26.715.2305.0 内置的 Codex CLI 0.144.1 开始实际遵循 GPT-5.6 catalog 中的 use_responses_lite=true。在 Responses Lite 模式下，Codex 不会注册托管的 web_search，而是依赖另一套独立的 web.run executor。

这对官方运行环境可能成立，但 Codex++ 的主要用户场景是使用第三方 URL 与 API Key 接入标准 Responses API。这类供应商通常支持 OpenAI 托管 Web Search，却没有 Codex 内部的 web.run executor。最终会出现：

• catalog 明确声明 supports_search_tool=true；
• 相同 URL、Key 和模型在其他客户端可以联网；
• 但从 Codex++ 启动的新任务完全没有暴露 web_search 工具。

这是新版 App/CLI 更新带来的静默能力回归。请求本身不会明显报错，用户只会发现模型突然无法联网，因此很容易被误判为供应商、模型或 Key 的问题。

修复方式

• Codex++ 为第三方供应商生成的模型 catalog 强制使用标准 Responses：use_responses_lite=false。

• 保留 supports_search_tool 和 web_search_tool_type 等搜索元数据。

• 当用户已经配置外部 Lite catalog 时，不原地修改用户文件；复制为 model-catalogs/<profile>.json 管理副本，只在副本中关闭 Lite，并更新当前 profile 指针。

• 仅对自定义供应商且 wire_api="responses" 的配置执行迁移；官方模型和官方登录路径保持不变。

• 同时兼容 TOML 双引号基础字符串与单引号字面量字符串。后者对 Windows 绝对路径尤其重要，例如：

  model_catalog_json = 'C:\Users\name\.codex\gpt56-model-catalog.json'

为什么不能只修改原 catalog

外部 catalog 可能由用户、其他工具或 Codex App 自身维护。原地修改会破坏所有权边界，也可能在下次更新时被覆盖。本 PR 使用 Codex++ 管理副本，使迁移可回滚、按供应商隔离，并保留原始文件作为来源。

验证

• cargo fmt --all -- --check
• git diff --check
• cargo test -p codex-plus-core --test model_suffix -j 2：14/14
• cargo test -p codex-plus-core --test relay_config -j 2：102/102
• 回归覆盖单引号绝对路径、管理副本写入、原文件不变、搜索元数据保留。
• 已在 Codex App 26.715.2305.0 的 API Key / Custom Responses 真人环境验证：重新启动并创建新任务后，联网工具成功恢复并暴露。

希望尽快合并。若不处理，使用第三方 Responses API 的用户会在新版 App 中静默失去 Web Search，即使供应商和模型本身完全支持联网。

---

English

Problem and impact

The Codex CLI 0.144.1 bundled with Codex App 26.715.2305.0 now honors use_responses_lite=true from the GPT-5.6 catalog. In Responses Lite mode, Codex does not register hosted web_search; it expects a separate internal web.run executor instead.

That assumption may hold in the official runtime, but the primary Codex++ use case is connecting to a third-party URL with an API key through the standard Responses API. These providers can support hosted OpenAI Web Search while not providing Codex's internal web.run executor. The result is:

• the catalog still declares supports_search_tool=true;
• the same URL, key, and model can browse in another client;
• a new task launched through Codex++ exposes no web_search tool at all.

This is a silent capability regression introduced by the newer App/CLI behavior. Requests do not necessarily fail with an obvious error, so users can easily misdiagnose the provider, model, or API key.

Fix

• Codex++ generated catalogs for third-party providers now use standard Responses with use_responses_lite=false.
• Search metadata such as supports_search_tool and web_search_tool_type is retained.
• Existing external Lite catalogs are never modified in place. Codex++ copies them to a managed model-catalogs/<profile>.json, disables Lite only in that copy, and updates the active profile pointer.
• Migration is limited to custom providers using wire_api="responses"; official models and official-login behavior remain unchanged.
• Both TOML basic strings and literal strings are supported, including single-quoted absolute Windows catalog paths.

Why not edit the original catalog

An external catalog may be owned by the user, another tool, or the Codex App. Editing it in place would violate that ownership boundary and could be overwritten by a later update. A Codex++ managed copy keeps the migration reversible and isolated per provider while preserving the original source file.

Validation

• cargo fmt --all -- --check
• git diff --check
• cargo test -p codex-plus-core --test model_suffix -j 2: 14/14
• cargo test -p codex-plus-core --test relay_config -j 2: 102/102
• Regression coverage verifies literal-string absolute paths, managed-copy creation, unchanged source files, and preserved search metadata.
• Human validation passed on Codex App 26.715.2305.0 with an API-key Custom Responses provider: after restart, a new task exposed the browsing tool again.

An expedited merge would prevent third-party Responses users from silently losing Web Search on the newer Codex App even when their provider and model fully support it.