社区讨论LinuxDo
Codex Desktop → CLIProxyAPI → OpenAI 请求分析讨论可能的降智原因
Codex Desktop → CLIProxyAPI → OpenAI 请求分析讨论可能的降智原因 最近饱受codex降智之苦，身边的朋友们也多多少少受到了波折。遍寻方法无果，看到站内时不时有佬友说改改请求头就可能可以解决降智的问题，但没有看到任何具体的方法。 今天看到一个帖子： 我解决Codex降智的全过程与分析 - 搞七捻三 - LINUX DO ，佬的IP很纯净，经过摸索，改了个时区，静置了一会儿就不降智了，他说：“我想也许可能是静置后智商已经恢复，是第一次对话的环境导致账号再次降智。问题不是第二次对话，…
内容摘要
Codex Desktop → CLIProxyAPI → OpenAI 请求分析讨论可能的降智原因
最近饱受codex降智之苦，身边的朋友们也多多少少受到了波折。遍寻方法无果，看到站内时不时有佬友说改改请求头就可能可以解决降智的问题，但没有看到任何具体的方法。
今天看到一个帖子： 我解决Codex降智的全过程与分析 - 搞七捻三 - LINUX DO ，佬的IP很纯净，经过摸索，改了个时区，静置了一会儿就不降智了，他说：“我想也许可能是静置后智商已经恢复，是第一次对话的环境导致账号再次降智。问题不是第二次对话，而是还是环境问题。” 仔细一想，这句话确实有道理啊。感谢 kafukasun 佬友的探索，这个帖子在此基础上继续讨论：
我的环境是：
请求设备：MacOS 26.6.2，Codex Desktop/0.154.0-alpha.6.2
CPA部署设备：美国家宽，版本号7.2.144
账号：菲区pro x20
首先是请求头：
Codex Desktop 带着自己的身份（ User-Agent: Codex Desktop/0.154… 、 Originator: Codex Desktop 、 Session-Id / Thread-Id / X-Codex-* 全套会话头，以及一张 CPA 分发的 Authorization: Bearer sk-… ）把请求发给 CPA，途中 Cloudflare 会顺手贴上 X-Forwarded-For 等快递单；CPA 收到后做四件事：把快递单全部撕掉（清洗 X-Forwarded-* 、 X-Real-Ip 等溯源头）、把会话身份头原样转给上游（Session-Id、X-Codex-Turn-Metadata 等白名单，其余客户端头一律丢弃）、把 Authorization 换成真正的 ChatGPT OAuth token 并补上 Chatgpt-Account-Id 、最后强制把 User-Agent / Originator 改写成硬编码的 codex-tui/0.146.0 (Mac OS…) iTerm.app ，再用 Chrome TLS 指纹发出。于是 OpenAI 看到的就是一个干净的官方 CLI 请求。
请求头里是没有包含时区的，但包含UTC时间戳turn_started_at_unix_ms。
然后再看看请求体：
请求体中 Codex Desktop → CLIProxyAPI 与 CLIProxyAPI → OpenAI唯一的变化只是 CLIProxyAPI → OpenAI 在 body 顶层补了一个 "instructions": "" 字段（为了了伪装成cli发送的请求）。其他几乎是纯透传。
但在透传的请求里面，包含着：
<environment_context>
<cwd>/Users/mike/Personal/workspace/PORTAL2</cwd>
<shell>zsh</shell>
<current_date>2026-09-13</current_date>
<timezone>Asia/Shanghai</timezone>
<filesystem>…<file_system type="unrestricted"/></filesystem>
</environment_context>
这里面是包含时区信息的。
OpenAI的风控是黑盒的，看了很多帖子，普遍认为风控是多因素造成的，也许请求的时区真的算一个其中的一个维度呢？各方面都没啥问题的佬友，可以试试看有无作用。有降智处理思路的佬友，可以多指导，真的不胜感激。
18 个帖子 - 12 位参与者
阅读完整话题
via LINUX DO - 热门话题 (author: Mike)
相关链接：
https://linux.do/t/topic/2896640/21
https://linux.do/t/topic/2897213