@peakj #23 所以我说这东西取决于具体的安全性需求。Passkey 只能算是 What you have 而不是 What you know ，在安全性高的地方就需要另一种手段来证明你能提供 What you know 的信息。
多因素认证里的因素，就同时包含了 What you know 和 What you have ，确保你在场而且你醒着。

公司用的公司提供，自己写项目自己订的中转站的乞丐分组。

合不合理先不说，为什么 Passkey 可以证明你本人操作？这最多只能证明你本人在场。
比如你喝醉酒了躺沙发上，别人过来拿你手指一摸就进网站系统了，你醒来一看天塌了，如何。

系统具体安全性要看各个安全措施组合在一起的效果。比如我司是无密码登录，直接验证 Passkey 。但是登录公司网络本身需要密码。把我干倒了摸了 Passkey 但是没密码依然连不上公司内网。

为什么要不断调试……你的测试覆盖不能保证代码边界吗。

640K 内存大抵也够用了，不够用的话再用上扩展内存，4MB 什么事干不了啊。很难想象人类需要多达 2GB 的硬盘空间。IP 地址支持 200 万个网络数了，再怎么说全世界能联网的设备也不会超过 200 万台了吧。

用 mac 的也跑不了。
https://github.com/openai/codex/issues/33582 一个 Codex app 进程吃了 55G 内存把系统干爆了。

@hellopz #101 我司是 OpenAI 大客户，所有工程师所有的开发、所有的工作，都得用 Codex 。我们一个 org 一个月起码给 OpenAI 上供 6 位数的 token 钱。你以为我不想用 Codex Desktop 吗。但是一天的工作开始于整台电脑卡得动不了，任务管理器里几十个 git.exe 和几十个 taskkill.exe 卡在那里，CPU 使用率拉爆，我得花上班时间去想办法给 OpenAI 做 debug 然后清光我自己的会话记录从头开始，然后浪费掉的时间我还得晚上无偿加班补上，换谁不骂他一句史。

你说的对，他的各种操作，布局，确实是业界范例，确实大家都在抄，这些我都同意。但是你做得再漂亮，最基础的可用性却没有，那我只能当他是史。你买一辆车回来，这车外观流线型漂亮得不得了，座位也舒服，空间也大，开起来也舒服，唯独在高速公路上开的时候引擎会爆炸，你说这车是不是史。

github 上的 bug 贴你可以自己去看 https://github.com/openai/codex/issues/17229 https://github.com/openai/codex/issues/34260 https://github.com/openai/codex/issues/33776 https://github.com/openai/codex/issues/34691 https://github.com/openai/codex/issues/34592 https://github.com/openai/codex/issues/34879 https://github.com/openai/codex/issues/34001 https://github.com/openai/codex/issues/20933 https://github.com/openai/codex/issues/32562 https://github.com/openai/codex/issues/34014 https://github.com/openai/codex/issues/32324 https://github.com/openai/codex/issues/34594 https://github.com/openai/codex/issues/33875 https://github.com/openai/codex/issues/34014 https://github.com/openai/codex/issues/34666 https://github.com/openai/codex/issues/35008 https://github.com/openai/codex/issues/29499
还有几十条差不多的我就不贴了。至少你知道我不是在空穴来风。

哦还有差点忘了，之前 codex desktop app 每年能给你 SSD 写入 640TB 的无用日志。
后来 openai 看到 issue 了，号称修复了，现在大家发现依然给你频繁写日志。
这么些 p0 级的问题放在那那么久不弄好，我能说什么。

还有别看了我说的就以为只有 Windows 有问题。好几个同事用 macOS 的一样被卡得怀疑人生。之前同事实在受不了了，滚回去用 VSCode 里的 codex 插件了，因为插件可以手动装旧版，得追溯回去找不会把电脑搞到卡死的版本挑着用。

@hellopz 一个程序启动以后什么都不干闲置在那 CPU 直接吃满 8 个核心以上，背后每秒启动十几个 git 进程和 taskkill 进程轮番轰炸几个小时不带停，运行没多久就能把 dwm 窗口管理器搞到崩溃，github 上因为这事开 issue 的人数不胜数，修了几个月都没修好。项目和对话一多就必然会发生这个问题，而且唯一的解决方法是 factory reset 删除所有项目和会话历史记录，全部清零。

你告诉我一个这样的软件是不是史。

你 harness 做得再好，插件、技能、生态集成得再好，打开程序就卡死电脑的软件谁来用？
我现在就等着别人抄，把他的功能全抄去，然后只要不像 codex 那样一启动就卡死电脑，我立马换掉 codex 。现在没办法，我遇到了就删除所有历史记录，同事遇到了就让他们删除所有记录，就只能这样。

GUI 挺好的，但问题是 Codex Desktop App 是史。

另外 CLI 和 TUI 本质上是完全不同的东西，深入讨论的时候不应该混为一谈。比如 vim 本质上是 TUI ，放到图形界面 gvim 上也是同样的操作手段，甚至做成 vscode vim mode 也是同一回事。而 CLI 则是 grep/sed/awk 这堆东西。一旦你画出了窗口的样子，分割出了操作区域，加上了光标导航和快捷键，这就不能算是一个「 CLI 」式的 CLI 软件了。

就拿 codex 来说，直接运行 codex cli 是 TUI ，照样是人机交互式界面。真正的 codex cli 其实是 codex exec ，可以脚本化自动化运行，接受命令行输入，然后标准输出管道输出结果。

当然我本意不是要给其他人来挑刺，我的意思是大家讨论的时候可以先想一想此 cli 是否是彼 cli 。

TUI 好处是可以方便从 SSH 远程运行，但远程运行并非只能用 TUI 。Codex 的远程连接功能就可以从 Desktop 端通过 SSH 直连 Linux 服务器上的 CLI ，通过 codex app-server proxy 连接 codex app-server ，像本机直接操作一样操作远程主机上的 agent 。

你交接文档去哪了，memory bank 去哪了。

有不同的模型对抗更好，但不意味着同一个模型就没有意义。模型切换视角也可以得出不同的结论。

不慌，我们用的 Jackson ，一样有洞要经常补。

和领导没多大关系。领导也不会因为员工在忙就不派活，该让你加班不还是会让你加班。

@iphantom 那就只是抠门而已，很正常的，谁不是呢。
怕有剩的那就找中转按量付费，没有剩余 token 一说，用多少付多少，就解决了。

领导让员工干活是压迫员工，员工让 AI 干活是解放员工。

花几秒钟搜一下你能找到不少，比如上面说的 sub2api 。我也是用这个反代给自己用的。