align: 记 MCP env 根因与端到端再测结论

- MCP 子进程不继承 Codex env，docker -e 无用，env 须
  写 config；手动加 env 后 web_search 立刻成功，代码
  修法 dc9b29e 已落地并经全新项目验证（config 自动
  写进 MCP env，web_search 5/6 成功）。
- 端到端仍未报出数字：web_fetch 4 次全败于 Tinyproxy
  403 Filtered，一级来源域名不在 egress 白名单里；
  下一层是主机白名单变更，另等用户定，非代码。
清理已核，用户剩余 0，生产 health fd9fe5f。

docs/chatgpt-codex-alignment.md

@@ -126,6 +126,38 @@
   钉住、env 覆盖、空值恢复），连同 MCP / worker 测试
   共 21 项全过。生产仍未部署此修法，live-info 端到
   端再测另等用户定。
+
+## MCP env 真正根因 + 端到端再测（2026-10-30）
+
+- 再测先失败，暴露了更深一层：临时 worker 新代码
+  跑 live-info，MCP 链只有 duckduckgo，DNS 瞬间失败，
+  而同一任务里 Codex bash 的 env 明明有 SEARXNG_URL
+  与 proxy。结论：Codex 的 MCP 子进程不继承 Codex
+  进程 env，docker -e 再全也没用，env 必须写进
+  config.toml 的 `[mcp_servers.websearch.env]`。
+  手动给租户 config 加 env 后，同一项目里 web_search
+  立刻返回真实北京天气 3 条，证实。
+- 代码修法（提交 dc9b29e）：`ensure_websearch_mcp_env`
+  写/替换租户 config 的 env 小节（其它小节不动，
+  空 env 不写），worker 在 `_docker_task_context`
+  算出网关后、容器启动前调用它（网关此时才已知）。
+  测试新增 `test_websearch_mcp_env.py` 4 项，相关
+  共 33 项全过。
+- 全新项目端到端再测（任务 537f8b7c，临时 worker
+  dc9b29e，生产未部署）：代码修法生效——租户
+  config 里自动写进了 MCP env（含网关 10.20.21.1:8888
+  的 proxy 与 SEARXNG_URL），技能 3 个都在，web_search
+  6 次里 5 次成功；但最终仍未报出天气与时间，因为
+  web_fetch 4 次全败于 Tinyproxy `403 Filtered`：
+  模型要 fetch 的一级来源（open-meteo、worldtimeapi、
+  timeapi.io、time.is 等）都不在 egress 白名单里，
+  搜索摘要本身又没有可靠数字。下一层修法不是代码，
+  是主机 egress 白名单加这些一级来源域名并 reload
+  tinyproxy（同时改仓库 deploy/egress/tinyproxy-filter，
+  否则下次部署会 revert），属生产安全配置变更，
+  另等用户定。清理已核：两次测试的用户/项目/任务、
+  租户目录与网络、临时代码全删，用户剩余 0，
+  生产 health 当时 fd9fe5f、worker_ok。
 - 清理已核：第二次测试的用户/项目/任务、租户目录、
   临时 worker 代码与临时 key 全部删除，用户剩余 0，
   生产 health 仍 3696dad、worker_ok；第一次测试的