最近在折腾Codex Desktop/CLI里官方OpenAI和第三方API的切换，踩了一堆坑，想问问有没有正确的打开方式。
我想干的事儿其实特简单：
官方模式：走 ChatGPT / OpenAI OAuth
第三方模式：走 API Key + base_url
切换时：历史对话别丢，provider 别乱，工具别掉
现在遇到的问题一堆：
- 切完provider，Codex里的历史对话就没了
切回原来的provider，有些对话又能回来，感觉session可能是和model_provider / provider name / auth的状态绑死的。 - 然后我查了下，可以手动给config文件加上对话对应的provider信息。但这么干，对话是回来了，可继续发消息时，走的还是对话原来配置里的那个服务商。
- 搞不清旧对话到底是用旧的provider，还是用当前
config.toml里配置的那个。 - 我自己还写了个小工具来切provider、同步/隔离记录
结果越搞越发现.codex里面session、sqlite、rollout、provider、auth、cache这些东西搅成一团，关系太深了。 - 后来看到CC Switch，以为能直接切换Codex的provider
实测下来对Codex Desktop好像没效果，或者效果不全。切完Desktop感觉还是走的官方，不确定是不是只对CLI有用。 - 又看到有人说可以搞个本地路由中转
思路是：
Codex -> localhost router -> 官方 OpenAI / 第三方 API
这样Codex就只认一个本地地址，后端靠router来切。
但我不确定Codex Desktop的OAuth、Responses API、streaming、tools调用这些能不能稳定地这样转发。
- 最后发现我本地的Codex环境也乱了
之前填过各种OPENAI_BASE_URL、OPENAI_API_KEY，还有第三方key，可能把官方provider给污染了。
还遇到过子进程重连报错、Chrome操控插件明明装了但工具不生效、插件缓存里缺了plugin.json这类问题。
所以后来干脆把Codex配置全清掉重装了。
现在主要想搞明白这几个事儿：
- Codex Desktop的provider优先级到底是啥？
是OAuth优先，还是config.toml/ env / cache / session这些优先？ - provider的名字会不会影响历史对话的显示？
为啥一切provider对话就没了？ - 在旧对话里继续发消息，到底是用旧的provider，还是用当前全局的provider？
- CC Switch到底能不能真正切换Codex Desktop？
还是说只对CLI比较有用？ - 官方OAuth和第三方API，应该共用一个
.codex，还是分多个CODEX_HOME来隔离？ - 本地搞个router中转是不是更稳？
有没有佬跑通Codex + LiteLLM / one-api / new-api / OpenRouter / 本地反代这套？
现在感觉搞个本地中转好像能实现热切还不串provider，毕竟在codex的配置里，provider没变，这个思路看起来没啥毛病。但是今天折腾得太晚了，脑子已经浆糊了，我先发出来，睡觉去了。
站里可能已经有相关的解决方案了，但我找了好久没找到，知道的佬能给指条路吗？