夜雨聆风一个在OpenAI内部做Codex的工程师，大半夜跑到X上抛出一个问题：你们觉得Codex有哪些早该解决、现在还没解决的毛病？ 他大概没想到，评论区瞬间被开发者的怨气淹没。2832个赞，2830条回复，47.7万次浏览。这条推文压根不沾产品发布、模型更新的边，纯粹是一次「求锤得锤」。
深夜一问，开发者集体开麦
北京时间7月5日早上7点36分，OpenAI Codex与ChatGPT团队成员Tibo（@thsottiaux）发了一条推文：
"What is something that you feel is surprising that Codex still can't do well and we should have gotten right a while ago?"
「开发者们，你们觉得Codex还有哪些令人惊讶的、我们早就应该做好的事情却一直做得不好的？」
▲ Tibo（@thsottiaux）的提问帖，截至发稿获得2.8K点赞、2.8K回复、47.7万次浏览。
Tibo本身就是Codex和ChatGPT团队里的人，粉丝17万+，之前还被媒体提到过参与Codex限流问题的紧急处理。这更像是内部人员主动把话筒递给用户，收集一手意见，而非哪个路人随口发牢骚。
评论区没有客气。开发者们排队列出一份长长的问题清单，从系统性的平台缺失，到细枝末节的界面卡顿，几乎每一条都带着"这都2026年了，怎么还没修"的火气。
连Claude都有了，Codex却连Linux都上不去
排在最前面、嗓门也最大的一条抱怨，来自开发者Shikhar（@xikhar）：
"No native linux version. Even claude has one now, cmon guys!"
「没有原生Linux版本。连Claude现在都有了，拜托各位！」
▲ Shikhar（@xikhar）的回复，436个赞，评论区一片附和。
这条抱怨绝非个例。往前翻几个月，OpenAI自家的开发者社区里，一个叫"Codex app for linux? please"的帖子已经挂了好几个月。有用户写道："被迫从Windows换到Ubuntu，结果最想念的就是Codex这个App，能不能给个Linux版，求你们了。"
有人支招，让他装CLI版本：sudo npm install -g @openai/codex，在Arch上能跑。但很快被人纠正，对方要的是桌面App，命令行工具帮不上忙。CLI能用，但App里那些并行线程管理、worktree可视化、代码审查面板、内置浏览器，CLI通通没有。对重度用户来说，这约等于同样交了订阅费，却被分到了功能残缺的版本。
翻开Codex官网首页会发现，这个落差写得明明白白：下载按钮下面只有两行小字，"Available on macOS and Windows"。Linux用户连个正式入口都找不到，只能在开发者文档里看到一行"Get notified for Linux"。
▲ Codex官网首页截图：下载按钮下方明确写着仅支持macOS和Windows，Linux仍停留在"通知我"阶段。
Electron架构本来就是为跨平台设计的，OpenAI员工也在社区里解释过：mac版本先做，是因为沙盒（sandbox）实现太难，Windows排在后面，2026年3月才落地原生沙盒支持，Linux则一直没排上号。听起来是技术优先级排序问题，但落在大量用后端、跑容器、天天泡在Linux机器上的开发者眼里，这就是"同一份订阅，二等公民待遇"。
会写代码，但写不好人话：文档里全是"内心独白"
如果说Linux是平台缺失，接下来这条吐槽，戳的是Codex最核心的能力，写代码和写文档。开发者Albert（@TheGreenCedar）的回复拿到了507个赞：
"I didn't get to try 5.6 yet, but as of 5.5, codex cannot in any realm write human-friendly documentation. It leaks its instructions and inner monologue straight into readme files and frontend widgets. It's terrible"
「我还没试过5.6，但到5.5为止，Codex完全写不出人类友好的文档。它会一股脑儿把指令和内心独白泄漏到readme文件和前端组件里。太糟糕了。」
▲ Albert（@TheGreenCedar）的回复，507个赞。
这条描述挺形象：一个原本该写给人看的README，结果里面混进了模型自己给自己下的指令、思考过程的碎片，甚至前端界面上都能看到不该出现的调试文字。对团队协作而言，这种"泄漏"很致命，文档本该是给同事和未来的自己看的说明书，结果混进了模型的自言自语，可读性瞬间崩塌。
这样的抱怨不止一两个人提过。多篇独立评测、GitHub上的功能请求，都在提同一件事：AI生成的内容里带着一眼能认出的痕迹，团队里的人看一眼就得回头手动清理。
前端和UI:一个词就是全部答案
要说评论区里最短却分量最重的一条回复，来自开发者geluhorotan，他只打了一个单词：
"Frontend"
「前端」
配了个视频演示，就这么一个词，收获750个赞，是整条评论区点赞数最高的回复之一。
▲ geluhorotan的回复，只写了"Frontend"一词，附带视频演示，750个赞。
紧接着，开发者Brahim Hamichan把话挑明了说："大家都在想这件事，我来说出来吧，UI。"414个赞。还有人说得更露骨："Codex的前端、UI、UX能力跟同行比起来简直是灾难级的。""做出好看的设计和界面"，成了Codex被点名最多的短板之一。
Reddit上有一条帖子的标题就叫"为什么Codex在前端/UI/设计上比Claude Code差这么多"，GitHub上也有开发者提交需求，要求"Codex需要自己的前端设计系统"。多个独立评测不约而同地提到同一个词：generic slop（廉价的、千篇一律的输出），布局松散，审美缺失，跟手工精心打磨的界面比，完全不占同一个量级。
有意思的是，社区里已经摸索出一套workaround：先让Codex内置的图像生成功能重新构思一版设计稿，再让它照着这张图去实现前端代码。据说这套流程在OpenAI内部关联人员那儿也验证有效。换句话说，Codex自己憋不出好看的界面，但先"看"一眼参考图，实现能力立马就跟上了。说到底，卡住Codex的，是审美这一关，代码能力早就达标了。
更深的坑:没有"记忆"，长任务说崩就崩
前面几条还算表层问题，评论区里也有人往更深处挖。开发者swift（@gaoscode）的回复点赞不算多（47个），收藏数反而更高，51个人把这条存了下来：
"Plans should become durable execution state. For long-running work, codex should materialize the plan into an editable task graph: prompts, acceptance criteria, review gates, logs, and resume state. Codex should have a plan system. Made a small mockup."
「计划应该变成持久的执行状态。对于长时间运行的工作，Codex应该将计划物化为可编辑的任务图：提示、验收标准、审查关卡、日志和恢复状态。Codex应该有一个计划系统。我做了一个小mockup。」
他还附了一张自己动手做的界面草图，画出一套任务节点图：单文件运行时、地形建模、玩法实体、渲染管线……每个节点都标着状态（已实现/进行中/待定），节点之间用线连着依赖关系。
▲ swift（@gaoscode）自制的"计划系统"mockup，51人收藏，比点赞数还高。
这条建议指向一个更本质的问题：现在的Codex在处理长任务时，靠压缩（compaction）来省上下文，但压缩就意味着丢细节。任务跑到一半，代理可能已经忘了三步之前定下的验收标准。开发者要的，并非更大的上下文窗口，而是一套"可编辑、可追溯、能恢复"的任务状态，出了问题能一路查回哪一步开始跑偏，别再对着一个黑箱干瞪眼。
评论区里类似的技术性诉求还有不少：多文件夹项目支持（目前一个project被限制在单个文件夹里）、worktree侧边栏的层级显示问题、1M上下文的实际需求。这些算不上"网红级"吐槽，却恰恰决定了Codex能不能撑起复杂工程任务。
藏在细节里的烦恼
除了这几大类，评论区还堆了一堆细碎但真实的抱怨：Computer Use（让代理亲自操作电脑屏幕、点鼠标敲键盘完成任务）跑完一个任务或者卡住了，居然不会主动提醒用户，只能干等着；密码管理器（比如Apple的Keychain）集成得很差，代理常常因为登不进网站就放弃任务；浏览器会莫名其妙屏蔽某些网站，原因也不透明；多账号之间切换，进度说丢就丢。
App本身的体验也被点名：Windows版本关闭预览窗口容易误触退出整个App，启动时输入卡顿；通用问题里，切换线程要等两三秒，Ctrl+R搜索慢，Git推送时不时失败；模型选择完全交给系统自动分配，用户想手动指定重模型都做不到。限流（limits）调整之后，重度用户开始为配额焦虑，这条在OpenAI开发者社区和Reddit上也被反复提起。
为什么这些"小毛病"格外让人破防
单看每一条，好像都算不上什么大问题。可放在一起看，事情就不一样了。
Codex现在的定位，是"最好的agent协作方式"，桌面App被包装成一个指挥中心，能同时开好几条并行线程，能用worktree把不同任务的改动互相隔离，能在后台跑自动化任务，甚至能亲自操作浏览器和电脑屏幕替你干活。画面挺唬人，像一支能自主作战的团队。
但团队要靠谱，光会干活不够，还得让人放心地"看得见、管得住、信得过"。写出来的文档不能混进模型自己的悄悄话，界面得过得去审美关，换个操作系统不能变成二等公民，长任务跑崩了得让人查得到原因。这些恰恰是Codex目前最弱的环节。
更别提，OpenAI自家的ChatGPT向来以打磨精细著称，用户对"OpenAI出品"的产品体验预期本来就被拉得很高。落到Codex桌面App身上，反差感自然更强烈，这也是为什么Tibo那句"surprising"（令人惊讶）用得挺准，开发者的失望里带着一种"你们不该是这个水平"的意外。
对比一下也挺说明问题：Claude Code在设计语言和界面实现上，经常被拿来当作参照物夸赞，改动更谨慎，不容易乱改文件；Cursor则主打模型选择的灵活性，可以自由切换Claude、Gemini等不同模型。不少重度用户干脆两边都用，用Claude Code做前端和界面，用Codex处理代码审查和需要深度推理的复杂任务。独立开发者zackproser在自己的评测里写得挺实在：Codex已经变得"不可或缺"，早上批量派发维护性任务、模式化工作，效率提升明显；但真正涉及架构决策的复杂活儿，他还是会留给Cursor或Claude来做。
这里面也有正面案例。金融科技公司Ramp把Codex的代码审查用到了生产环节，团队内部把它评价为"行业标杆级别"，靠的是持续、贴身的反馈循环，工程师提意见，团队跟进修，效果立竿见影。Tibo这条深夜提问，某种程度上就是把这套内部反馈机制搬到了公开平台上，规模从几个人扩大到几千个人。
编码代理下一步要补的课
把这些吐槽串起来看，能看出一条清晰的脉络：2021年那个只会从自然语言生成代码片段的Codex，到今天已经进化成一个能管理Git工作树、能操作浏览器、能后台自主跑任务的agent。生成代码的能力早就过关，真正的坎，卡在"生成之后"，代理跑起来之后，人类能不能看清楚它在干什么，能不能随时插手，出了错能不能一眼看出哪里错了。
这轮吐槽里被点名最多的几条，指向的其实是三件不同的事：Linux支持缺失，是平台承诺没兑现，跟模型能力关系不大；文档泄漏内心独白，是工程细节没打磨到位；UI审美不够，则触及一个更难的命题，审美这东西，恐怕没法只靠堆算力解决，还是得靠训练数据、设计系统积累和人类反馈一点点磨出来。
Tibo这条推文收到的，看着像一份差评清单，读起来更像几千个开发者共同交出的一份产品需求文档。OpenAI会不会认真看、认真改，接下来几个月大概会见分晓。毕竟据传Codex桌面App未来可能会成为ChatGPT和Codex融合的"超级应用"底座，如果连Linux、文档、界面这些基本功都补不齐，这个底座恐怕先得晃上一阵子。
