stop: cancel task, id_task = 2 Codex 超时覆盖

Quick fix

增大 startup_timeout_sec，并在 MCP 配置被二次覆盖后重新保存一次。

Symptom

报错原文复制

2.04.274.375 W srv          stop: cancel task, id_task = 2

Cause

本地 llama-server 通过 cc-switch 接入 Codex 时，首次启动会话需要较长 prompt 处理时间。日志中的 stop: cancel task, id_task = 2 与 Codex 的 startup_timeout_sec 过小有关；增大该值可避免任务被取消。

用户还观察到 ~/.codex/config.toml 会在 ChatGPT/Codex 启动时被 cc-switch 的 MCP 服务器配置覆盖一次，而在 Codex 第一次会话开始时又被覆盖一次，导致手工或 MCP 配置中改大的 startup_timeout_sec 被重置。第二次覆盖的数据来源在 issue 中未被维护者确认。

Fix

1. 1

   将 startup_timeout_sec 从 120 增大到更大的值，例如 1200，以避免本地模型启动/首条请求超时。

   C:\Users\user\.codex\config.toml

   startup_timeout_sec = 1200

2. 2

   如果配置由 cc-switch 的 MCP 服务器配置写入，则在 MCP 服务器配置中同步修改 startup_timeout_sec。

3. 3

   在 Codex 开始第一次会话后，如果 config.toml 再次被覆盖回 startup_timeout_sec = 120，请再次修改并保存 MCP 配置文件；用户反馈后续会话不会再覆盖，错误也不再出现。

Affected Versions

ToolCodex

Version未知

PlatformsWindowsmacOS

Source Issues

本页汇总自 2 个真实 issue

• #4499模型调用错误导致无法连接
• #6032stop: cancel task, id_task = 2

FAQ

config.toml 为什么要被覆盖两次？

issue 中观察到 ChatGPT/Codex 启动时会用 cc-switch 的 MCP 服务器配置文件覆盖一次，第一次会话开始时又覆盖一次；第二次覆盖的数据来源未被确认。

为什么修改 MCP 配置文件后第一次会话仍会失效？

第一次会话开始时 config.toml 会再次被覆盖，startup_timeout_sec = 1200 可能被重置为 startup_timeout_sec = 120；再次保存 MCP 配置后，后续会话用户反馈不再覆盖。

stop: cancel task, id_task = 2 是否一定是 cc-switch 导致？

该日志来自 llama-server，issue 中用户将其与 Codex 的 startup_timeout_sec 超时关联；增大超时后问题可避免，但根因未在 issue 中由维护者最终确认。

相关问题

在codex中打开不显示使用的模型列表，切换不了模型 Codex在 cc-switch 中开启“切换第三方时保留官方登录”，并确保已在 Codex 登录过官方 ChatGPT 账号，即可恢复第三方模型显示。6 issues merged无法使用谷歌邮箱登录的codex账号 - Codex升级 cc-switch 至 v3.16.1+，或手动修改 ~/.codex/auth.json 恢复 auth_mode 为 chatgpt 并清空 OPENAI_API_KEY。7 issues mergedError running remote compact task 报错 - Codex升级 cc-switch 至 v3.12.0 或更高版本，该版本在本地代理中新增了对 Codex `/responses/compact` 路由的转发支持，可解决 404 或 502 报错。3 issues merged