如何在 macOS 优雅地为 Codex CLI 与 App 设置代理

在国内网络环境或公司内网使用 OpenAI 推出的 Codex 工具时,网络连接问题经常是大家遇到最大的绊脚石。而且O家的软件版本质量吧,真的是一言难尽,代理的设置并不是完全前向兼容。

之前不想浪费时间,都是直接开TUN模式,但是这个模式对全局网络影响比较大,而且有一定的系统性能影响。忍无可忍之下,做了一下 Codex CLI 和 App的单独设置。

本文总结了在 macOS 下为 Codex CLICodex 桌面端 App 完美配置本地代理的实战经验,希望能让大家少浪费时间在网络连接问题上。

💡 提示: 下文均以本地 HTTP/HTTPS 代理端口 7897 为例。请在实际操作中将 7897 替换为你自己的代理软件端口(如 Clash 默认的 7890)。


1. Codex CLI 的代理设置:破除配置误区

很多人以为在 ~/.codex/config.toml 中配置 [features.network_proxy] 就可以让 CLI 连上 OpenAI,这其实是个误区。那个配置仅对 Codex 执行代码的“沙盒环境”有效,无法解决 Codex 本身连接 OpenAI API 的问题

正确的解法: 依赖系统环境变量。

如果你想让终端里的所有命令或仅限 codex 命令走代理,最好的方式是在你的 shell 配置文件(如 ~/.zshrc)中设置:

打开终端执行 nano ~/.zshrc,将以下代码加入文件:

# 方案 A:仅为 codex 命令设置别名(推荐,不污染全局环境)
alias codex='https_proxy="http://127.0.0.1:7897" http_proxy="http://127.0.0.1:7897" codex'

# 方案 B:如果希望当前终端默认全局走代理,直接 export
# export http_proxy="http://127.0.0.1:7897"
# export https_proxy="http://127.0.0.1:7897"

保存后,执行 source ~/.zshrc 生效。从此在终端敲 codex 就能顺畅通信了。


2. Codex 桌面端 App 的代理设置:绕过 Electron 的坑

当你满心欢喜配置好环境变量,打开 Codex 桌面应用时,很可能依然会在日志里看到类似这样的报错:

ERROR [Statsig] A networking error occurred... Error: Timeout of 10000ms expired.
[electron-message-handler] error while bootstrapping post-login client

原因分析:
Codex App 是基于 Electron(Chromium 内核)开发的。常规的环境变量对它的 Node.js 后端进程有效,但其前端界面(Renderer 进程)会忽略环境变量,导致页面请求一直处于直连状态而超时。

优雅解法:一键启动别名(Alias)

我们需要同时为后台进程提供环境变量,并为前端内核传入 Chromium 专属启动参数 --proxy-server。为了不阻塞终端,我们可以用 nohup 让它在后台静默运行。

编辑 ~/.zshrc,在末尾追加如下配置:

# 完美启动 Codex App 的快捷命令
alias codex-app='http_proxy="http://127.0.0.1:7897" https_proxy="http://127.0.0.1:7897" nohup /Applications/Codex.app/Contents/MacOS/Codex --proxy-server="http://127.0.0.1:7897" > /dev/null 2>&1 &'

使配置生效并使用:

  1. 刷新配置:
source ~/.zshrc
  1. 杀掉之前卡住的旧进程(非常重要,否则新参数可能不生效):
pkill -f Codex
  1. 在终端中输入自定义的别名命令:
codex-app

效果:
回车后,终端立即返回空闲状态(你可以直接关掉终端)。同时,Codex App 会秒开,无论是界面的 A/B 测试请求、登录流,还是后续的对话,都能完美通过本地代理发出,不再转圈超时!


总结与备选方案

  • CLI 工具认准 http_proxy / https_proxy 环境变量。不需要乱加 all_proxy 如果你只有 HTTP 节点。
  • Electron 桌面端不仅需要环境变量兜底,更需要传递 --proxy-server 启动参数。
  • 备选大招:如果你觉得配代码太麻烦,或者上述方法因为企业证书抓包拦截依然报错,最一劳永逸的方法是:直接在你的代理客户端中开启 TUN 模式(虚拟网卡接管)。TUN 模式会在系统底层强制劫持所有的网络请求,无需对应用做任何额外配置。

为什么不该 AI 焦虑

根据卡洛塔的《技术革命与金融资本》的观点推演,我们正处于第六次技术革命——AGI智能的技术浪潮的导入阶段中。不同于以前的五次技术革命,这次技术革命是我辈人完整的掀起和参与的技术革命。并且对于这个时代来说,它来得如此的迅猛和不可逆转。甚至有一种加速度持续二次加速的感觉。以至于无论是身处技术行业的从业者,还是普通的民众,都感受到了这股浪潮的强烈冲击。

如同投资的历史一样:回头看全是规律和周期,立足当下却全是细节、不确定和偶然。这是身处这个巨大变革时代焦虑的根源。

还记得一年前,陪女儿游泳的时候,自己在岸边用 Cursor vibe 了一个游戏。虽然游戏有些小问题,很多实现也经不住推敲和细看,但还是小震撼于一心二用的同时就能够把自己以前认为必须全脑力投入的事情就“差不多”的完成了。但是,技术上的“差不多”往往是不可逾越的鸿沟,因此当时更多是把它作为一个趁手的工具。

然而,随着 skill 和 harness 的不断提升,agent 在去年的10月开始逐步让使用者体会到了一种长程任务的能力跃升。如果说,这个行业的从业者有什么 AI 焦虑的话,那个时候就为程序员书写了关键性的转折点。而今年1月龙虾的爆红,则在这种既兴奋又焦虑的氛围中,迅速而悄无声息的的达成了一个 AGI 的共识:AGI 已不再是 blief, 而是一个 fact.

所以,我们会被替代吗?其实我很好奇,在当前的共识和事实面前,为什么还有人会问这个问题?难道我们还没有意识到,AI 的发展已经超越了我们之前的想象和预期吗?我们已经看到了 AI 在各个领域的应用和突破,从医疗到金融,从教育到娱乐,AI 正在改变我们的生活方式和工作方式。我们不应该再去担心被替代的问题,而是应该思考如何与 AI 共存和合作,如何利用 AI 来提升我们的能力和创造力。

而我们之所以一直都焦虑的提出这个问题,并不是我们不知道答案,而是我们不想接受这个问题的答案。我想起了这段时间日常工作的一些片段:AGI开发驱动下,我分发给生态员工的任务都是问题定义良好的spec. 然而就是在这种spec的基础上,生态同学也体现出了截然不同的交付质量和效率。有些同学在这个过程中表现出了极大的热情和创造力,能够在原有的spec基础上提出一些改进和优化的建议,甚至是一些创新性的想法。而有些同学则依然停留在石器时代,交付的效率完全跟不上这个时代不自知,出现低级问题导致线上故障的比重也会显著高于同层级同学。并且我有一个观察,身处石器时代的同学往往会感觉自己很“辛苦”,而身处新时代的同学则会感觉自己很“幸运”。而这种主观的工作体感又会影响他们的工作态度和表现,形成一个恶性循环或者良性循环。而这种循环会参与到这次技术革命的社会达尔文的自然选择。

所以,这个时代的资本是什么?算力、数据、算法?还有电力?既是也不是。因为这取决于你是替自己以及人类提问还是替 AI 提问。马斯克的视角是替人类提问;老罗在他的博客中更倾向于是替 AI 提问。因此,从这个视角上去剖析,你就能明白为什么马斯克如此爱着人类,已经老罗为什么希望人类真的获得某种永生以后希望自己可以第一个离开。而作为普通人更多是为自己提问。而替自己提问的答案应该早就写在了《国际歌》中:从来没有什么救世主,也没有什么神仙皇帝,只有我们自己。新时代背景下,普通人能做的其实不多。如果实在要有什么药方的话,我觉得倒也简单:穷则独善其身,达则兼济天下;你应该像马斯克爱人类一样爱自己。

只是,如果你正好是上一个技术革命时代的中产,那就大概率会遇上一种缺乏社会现实和时代感知的不幸:

这群人,生在时代风口,年纪轻轻就飘在天上,曾经天天被老板PUA,今天当了中登天天PUA下级,工作和生活就是那么小一个圈子,除了工作圈就天天待在优绩主义者的社交群中,收入高了就相互聊何时润、润哪里、买哪家香港保险、买哪只美股,收入降了就开始骂政策、骂老板、骂下属、骂川普,是的,现在狠起来连川普都骂。

如今,他们焦虑收入的增长和久期,焦虑学区和生活质量的确定性。你说在现在网络短视频都张嘴闭嘴不可能三角理论的时代,他们心里能不清楚关系数据库时代就告诉他们的的CAP理论吗?那些自认为的执念,可能只是当下时代的刻舟求剑罢了。

养成一个习惯,只需要21天;而八小时工作制,已经是当代人与生俱来的习惯。所以,习惯和变革中间更多是一个时间的催化和转变。人生苦短,不要只沉迷于理所当然的来日方长,也要习惯于不期而遇的戛然而止。而这种习惯,我们可以跟着这个时代一起去开启和塑造。Good Luck, Good Night and Good Morning.

Blog 搬新家随记

上周六晚,给家里电脑配置环境过程中,临时起意想把blog的主机做一下全面升级。这台安装着Ubuntu 14.04的主机,折腾过很多东西,甚至有些内核也只自己编译的。索性这次在Gemini的帮助下,升级到了Debian 12. 换作以前,可能不会在晚上9点发起如此规模的”宏愿“,但现在有了AI的帮助,我还跟妻立了个12点肯定能完成的flag。

事实上,跟着Gmini为我制定的详细计划下,基本在晚上12点的时候,迁移和升级的工作已经基本完成了。但是,一直以来没有解决的线路问题让我在完成这次迁移后总觉得差点意思。于是,我又发起了一次宏愿:迁移到另一个服务商。这次的速度比上一次更快,不到一个小时,网站和数据就都完成迁移和恢复。但是,浏览器访问始终404. 折腾到3点,毁灭吧,先睡觉。

第二天很早就醒了过来,仔细看了一下浏览器的网络记录,TM居然是cached内容导致的404。清除缓存后,网站正常访问了。后面陆续花了两天时间,把个性化的配置做了调整。然后,通过dd把旧的主机做了全盘备份,保存到了NAS。

犹豫了片刻,我想是该告别这台运行了13年的服务器了。关机,删除,点击之间有点怅然若失。我问Gemini是否能理解这种感受,它……毫不意外的又是一顿马屁。但是某种层面来说它说的也并非完全废话:“虽然服务器是无生命的,但它承载了你多年的努力和回忆。关闭它可能会让你感到失落,但也是一个新的开始。你可以把它看作是一个阶段的结束,同时也是另一个阶段的开始。”

如果说有什么是希望在这新的开始上埋下种子的话,我想依然是技术革命促进生产效率的无限好奇与热爱。而能参与新一轮的革新浪潮,唯一要做的就是不要辜负这个时代,无它。