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

首先是请求头：

请求头 |
入站（Desktop → CPA） |
出站（CPA → OpenAI） |
处理方式 |

Authorization |
Bearer sk-J***（CPA key） |
Bearer eyJ***（OAuth JWT） |
替换 |

User-Agent |
Codex Desktop/0.154.0-alpha.6.2 (Mac OS 26.6.2; arm64)… |
codex-tui/0.146.0 (Mac OS 26.5.0; arm64) iTerm.app/3.6.10… |
伪装改写（写死常量） |

Originator |
Codex Desktop |
codex-tui |
伪装改写 |

Chatgpt-Account-Id |
— |
78c2734e-… |
新增（OAuth 账号 ID） |

Session-Id |
01a09a1e-… |
原值 |
白名单透传 |

Thread-Id |
01a09a1e-… |
原值 |
白名单透传 |

X-Client-Request-Id |
01a09a1e-… |
原值 |
白名单透传 |

X-Codex-Window-Id |
01a09a1e-…:0 |
原值 |
白名单透传 |

X-Codex-Turn-Metadata |
{installation_id, session_id, sandbox: “danger-full-access”, turn_started_at_unix_ms: 1789293131822, …} |
原值 |
白名单透传（全链路唯一的时间信息就藏在头的这个 JSON 字段里：epoch 毫秒、无时区语义；body 的 client_metadata 中还有重复一份） |

X-Codex-Beta-Features |
remote_compaction_v2 |
原值 |
白名单透传 |

X-Openai-Internal-Codex-Responses-Lite |
true |
原值 |
白名单透传 |

Accept / Content-Type |
text/event-stream / application/json |
同 |
透传 |

Connection |
close |
Keep-Alive |
重写 |

X-Forwarded-For / -Host / -Port / -Proto、X-Real-Ip / -Port、Remote-Host |
Cloudflare/反代附加 |
全部消失 |
溯源头清洗 |

Accept-Encoding |
gzip |
删除（Go 运行时自动补 gzip） |
清洗 |

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的风控是黑盒的，看了很多帖子，普遍认为风控是多因素造成的，也许请求的时区真的算一个其中的一个维度呢？各方面都没啥问题的佬友，可以试试看有无作用。有降智处理思路的佬友，可以多指导，真的不胜感激。