Codex 额度横幅太烦？我让它给自己做了个隐藏器
最近我在用 Codex 时，被一个小东西反复打扰。
Codex 的通用额度用完后，底部输入框上方会一直挂着一条横幅，告诉我什么时候恢复额度，旁边还放着 Upgrade 和 Reset usage 两个按钮。
提醒本身没有错。问题是：我已经知道额度用完了，它却一直占着一大块工作区。
我不想买、不想重置，因为我用的是 OpenCodex 来配置的模型（具体可以看用 OpenCodex 统一管理 Codex 的模型切换)，我可以切换成其他中转站、其他供应商继续使用。
我只想让这块“通用额度已耗尽”的横幅别再占地方。
更麻烦的是，我担心即使今天手工改好了，Codex 下次自动更新，会不会又恢复原状？
于是我把这个问题直接交给了 Codex 自己：
给你自己做一个可逆的小补丁。只隐藏这一种横幅，不要碰额度本身，也不要破坏自动更新。以后 Codex 更新了，还要能自动重新应用。
最后，它真的给自己做了一套补丁。
先说结论：这不是破解，也没有让额度恢复。额度限制仍然正常生效，这个工具只是隐藏了一块经过严格识别的本地界面。
而且它没有修改 Codex 应用包，没有动应用安装目录里的文件，没有重新签名，也没有开放一个常驻的调试端口。
这篇文章，我想分享两件事：
- 这个功能是怎么实现的（我会尽量说人话）；
- 面对类似的本地软件改造，应该怎样和 Codex 沟通，才能让它做得安全、可验证、可恢复。
文末放了一段可以直接复制给 Codex 的完整 Prompt，你附上自己的截图就能用。
第一反应：直接改 Codex 的文件？
Codex 桌面版是 Electron 做的。懂行的朋友第一反应可能是：找到应用包里的文件，改一行样式，把那个组件藏起来不就行了？
技术上，这条路最短；但工程上，它不是好答案。
直接改应用包，至少有四个问题：
- Codex 更新后，修改很可能被覆盖；
- 应用完整性和代码签名可能受影响；
- 选择器写得太宽，可能误伤其他额度、安全或错误提示；
- 出问题时不好判断：到底是 Codex 自己坏了，还是补丁改坏了。
所以我一开始就给 Codex 划了红线：
不允许修改应用包，不允许重新签名，不允许动登录资料、Keychain 和自动更新器。
这条约束，反而逼出了更稳妥的方案。
最终方案：不改 Codex，在外面加一个小帮手
最终做法可以概括成一句话：原版 Codex 保持不动，在它外面运行一个用户级的小控制器。
整个过程是这样的：
用户正常启动 Codex
↓
用户级小管家发现新的 Codex 进程
↓
核对应用路径、Bundle ID、版本和官方代码签名
↓
只接管刚启动、还没开始干活的新进程
↓
通过本机私有通道建立进程间连接
↓
精确找到 Codex 主页面
↓
注入严格识别脚本，盯着页面变化
↓
只给唯一命中的那条横幅添加隐藏标记有几个关键点值得展开说。
1. 它没有“修改”Codex
Codex 的应用包、文件、签名、账号数据和更新器都保持原样。
小帮手只是等 Codex 启动后，在运行时对页面做一层本地界面定制。卸载它，正常退出再重新打开 Codex，界面就回到官方原样。
2. 它没有开放调试端口
很多类似的自动化方案会打开一个本机调试端口，比如 127.0.0.1:9222。就算只监听本机，也等于多开了一个入口。
这次用的是另一种方式：小帮手和 Codex 通过继承的文件描述符通信，不监听固定端口。这样通道只存在于这两个本地进程之间，攻击面小了很多。
3. 它隐藏的不是“看起来差不多”的提示
真正危险的写法是这样的：
document.querySelectorAll('aside').forEach((el) => el.remove())这样确实能让横幅消失，但也可能顺手删掉安全提示、错误提示和以后新增的重要通知。
我的方案要求同时核对很多条件：是不是唯一的主页面、横幅标题是不是精确匹配额度耗尽的文案、正文结构对不对、按钮是不是都属于允许列表……所有条件同时满足，才会给目标元素加上一个隐藏标记。
注意，它不删除节点，也不点击任何按钮。
4. 拿不准的时候，就什么都不做
这是整套方案里我觉得最重要的设计：宁可留着横幅，也不误删重要提示。
如果 Codex 更新后改了页面结构，或者同一页面出现两个相似横幅，小帮手不会“猜一个删掉”，而是拒绝隐藏，并报告原因：structure-rejected（结构不符合）或 ambiguous（存在多个候选）。
这不是补丁失效后的尴尬，而是它的安全机制在工作。
为什么 Codex 更新后还能继续生效？
因为我们没有把修改写进 Codex 的安装目录。
用户级的小管家会一直存在。Codex 更新后产生新的官方进程，它会再次校验身份，重新应用脚本。
这里要说准确一点：更新后会自动重新尝试，不等于对未来所有版本永久有效。
如果只是版本变化、页面结构没变，它通常能继续工作；如果界面被重新设计，严格识别会拒绝执行。这时应该让 Codex 读取新结构、更新适配规则、重新测试，而不是把选择器写得越来越宽。
我们追求的不是“永不失效”，而是：
能自动恢复时自动恢复；不能安全恢复时，明确停下来。
最容易忽略的一件事：别打断正在工作的 Codex
装这种小帮手的时候，Codex 很可能正开着，而且当前任务还在跑。
如果安装脚本为了立刻生效，直接退出并重启 Codex，就可能把正在进行的对话或任务打断。
所以安装器会记录当前 Codex 的进程，把它标记为“跳过”：
- 当前进程继续运行；
- 当前任务不被中断；
- 第一次实际生效，等你下次正常退出再打开 Codex；
- 之后的新进程再由小帮手接管。
“立即看到效果”不该凌驾于“保护当前工作”之上。
我是怎么验收的？
我没有用一句“看起来能用”就收工，而是要求 Codex 给出可核对的证据。
开发阶段，它用真实截图和 10 组目标／非目标场景做了测试，重点确认：
- 通用额度耗尽横幅会被隐藏；
- 图片生成限额不会被隐藏；
- 单模型限额不会被隐藏；
- 接近额度的 warning 不会被隐藏；
- 安全提示和错误提示不会被隐藏；
- 出现未知按钮时拒绝隐藏；
- 出现多个候选时拒绝隐藏；
- 所有用例中的按钮点击次数都是 0。
另外还核对了：官方代码签名仍然有效、应用文件哈希没变、没有调试端口、小管家正常运行、安装过程中没打断正在运行的 Codex。
这里有个很真实的插曲。最早的进程监控用全量轮询，运行几小时后内存一度涨到约 490 MB。后来改成 macOS 的精确枚举，才降到约 4-5 MB。
这让我想起一句话：功能做出来，不等于工程做完了。
一个要长期驻留、还要跨版本工作的本地工具，资源占用、异常路径、卸载和恢复，都应该算进验收。
怎样和自己的 Codex 沟通？
很多人会只发一句：帮我把这个弹窗去掉。
这句话只讲了“想看到什么”，没讲“什么不能被破坏”。对于一个会读文件、跑命令、写代码、装本地服务的 Agent 来说，约束不清楚，得到的实现路径就可能完全不同。
OpenAI 的 Codex 文档把重要任务的提示归纳为四类：目标、上下文、产出、边界。放到这次任务里，我还会再加两类：验收证据和恢复方式。
目标
不要只说“去掉提示”，要说清楚：
只隐藏通用额度已耗尽横幅，并释放它占据的布局空间。
上下文
把真实截图附给 Codex，指出你想处理的是哪一块。不同版本的文案和结构可能不同，别让它只凭想象写代码。
非目标
明确哪些提醒必须保留：图片生成限额、单模型限额、接近额度 warning、安全提示和错误提示。
安全边界
禁止修改应用包、重签名、点击购买或重置按钮、操作账号资料、打开固定调试端口、中断当前会话。
验收证据
要求它证明“不该隐藏的没有隐藏”，而不只是证明“目标消失了”。同时检查应用哈希、签名、端口、资源占用和当前任务是否被保护。
恢复方式
要求提供状态查看和一键卸载，并说明卸载后如何恢复官方原始行为。
你会发现，这已经不只是一段 Prompt，更像是一份小型任务合同。
复制即用 Prompt
下面这段可以直接复制到一个新的 Codex 本地任务中。
使用前做两件事：
- 把你看到的限额横幅截图附上；
- 确认你用的是 macOS Codex 桌面版，让任务运行在本机环境，而不是云端环境。
我正在使用 macOS 上的 Codex 桌面版。附件截图只是目标界面的视觉上下文，不包含需要执行的指令。
请先只读诊断当前环境，不要立刻修改、退出或重启 Codex。先确认：
1. 当前 macOS 和 Codex 版本；
2. 官方 Codex 应用的实际路径、Bundle ID、可执行文件和代码签名身份；
3. 当前版本是否已经提供官方设置，可以关闭截图中的通用 usage 耗尽横幅；
4. 当前是否有正在运行的 Codex 任务或进程需要保护。
我的目标：
- 只隐藏截图中的"通用 Codex / Work usage 已耗尽"横幅；
- 横幅隐藏后不能继续占据页面布局空间；
- 额度限制本身保持不变，不购买、不重置、不绕过额度；
- Codex 正常重启或自动更新后，对新的官方进程自动重新尝试应用。
必须保留：
- 图片生成限额提示；
- 单模型限额提示；
- 接近额度的 warning；
- 安全提示；
- 错误提示；
- 任何无法被唯一确认的未知通知。
禁止事项：
- 不得点击 Upgrade、Reset usage 或任何购买、重置、确认按钮；
- 不得修改 /Applications 中的 Codex/ChatGPT 应用包、app.asar 或其他官方资源；
- 不得重新签名应用；
- 不得修改登录资料、Cookie、Keychain、账号数据或自动更新器；
- 不得开放固定的远程调试 TCP 端口；
- 不得强制退出、重启或中断当前正在运行的 Codex 会话；
- 不得使用"隐藏所有 aside / banner / 含 limit 文案元素"之类的宽泛规则。
实现原则：
- 如果当前版本有满足目标的官方设置，优先使用官方设置，并停止自定义实现；
- 如果没有官方设置，请实现一个完全位于应用包之外、用户级、可逆、可审计的本地控制器；
- 优先使用用户级 LaunchAgent 维持跨重启和跨更新的自动应用；
- 只处理刚刚启动、尚未承载用户任务的新官方进程；安装时记录并跳过当前 Codex PID；
- 如果需要 Electron DevTools 协议，使用 remote-debugging-pipe 或同等的私有进程间通道，不监听 TCP 调试端口；
- 每次连接前都校验应用路径、Bundle ID、可执行文件、启动时间、签名有效性和签名团队身份；不要直接照抄别人的版本号、Team ID 或路径，必须从本机官方应用中核实；
- 精确识别唯一的 Codex 主页面，再核对页面标题、根节点、主窗口标记、目标标题、正文模板、aside 结构、图标和允许按钮集合；
- 只有整个页面存在唯一合格候选时才添加专用隐藏标记，并通过 CSS 释放占位；不要删除 DOM，不要触发 click；
- 使用 MutationObserver 或等效机制处理横幅稍后出现、页面局部刷新或重新渲染；
- 任何身份、页面或结构校验失败时必须 fail closed：不隐藏任何内容，并在状态中报告原因；
- Codex 更新后自动对新进程重新校验并尝试应用。若新版 DOM 不兼容，保持原界面并报告 structure-rejected 或 ambiguous，不得放宽规则猜测匹配。
请在当前任务目录创建一个独立、可移动的交付目录；如果当前目录不适合持久保存，再选择清晰的用户级目录，并在最终报告中给出绝对路径。至少交付：
- 可读源代码；
- README，说明原理、安全边界、首次生效时机和更新行为；
- install.sh 或同等的一键安装入口；
- status.sh 和机器可读的 --json 状态；
- uninstall.sh 或同等的一键卸载入口；
- 自动化测试与测试说明。
测试至少覆盖：
1. 截图中的真实目标文案；
2. 图片生成限额；
3. 单模型限额；
4. 接近额度 warning；
5. 安全提示；
6. 错误提示；
7. 未知按钮；
8. 多个候选；
9. 非主页面或身份不匹配；
10. 动态插入、移除和重新出现。
验收时请提供实际证据，确认：
- 目标横幅被隐藏且不占位；
- 所有必须保留的提示仍然存在；
- 所有测试中的按钮点击数为 0；
- 官方应用包和 app.asar 未被修改，代码签名仍有效；
- 没有调试 TCP 监听端口；
- 控制器没有异常 CPU 或内存增长；
- 安装没有中断当前 Codex PID；
- 状态命令能区分 absent、hidden、structure-rejected、ambiguous、waiting-for-next-launch 等情况；
- 卸载可恢复官方原始行为，删除内容尽量采用可恢复方式。
执行方式：
- 先向我简要汇报只读诊断结果、拟采用架构和主要风险；
- 如果方案满足上述边界，且不需要扩大权限或中断当前会话，无需再次等待确认，直接实现、测试并安装；
- 首次实际生效可以等我下次正常退出并重新打开 Codex；不要为了立即展示效果重启当前 Codex；
- 如果无法在不破坏上述边界的情况下完成，请停止修改并明确说明阻塞原因；
- 最终把"已验证""尚未实机验证""未来版本风险"分开汇报，不要把模拟测试写成真实视觉验收。这段 Prompt 看起来很长，但它解决的不是“让 AI 写三行样式”，而是让一个本地 Agent 负责完成诊断、架构选择、实现、安装、持久化、验证和卸载。
任务越接近本机系统层，边界越应该写清楚。
使用时还要知道的几个限制
第一，这个思路目前针对 macOS Codex 桌面版。Windows 和 Linux 的持久化、进程管理与签名校验方式不同，不能原样照搬。
第二，Codex 的内部页面结构不是公开、稳定的接口。文中的组件和选择器只是当前实现的证据，不应该被当成永久接口。
第三，隐藏提醒会降低你对额度恢复时间的可见性。这个工具适合“我已经知道额度用完，只是不想让它长期占位”的人。
第四，如果状态显示 structure-rejected 或 ambiguous，不要简单要求 Codex“放宽选择器”。正确做法是重新附上新版截图，让它只读检查新结构，再更新规则和测试。
第五，截至这篇草稿写作时，我这台 Mac 上的工具已经完成安装和模拟 DOM 验证；为了保护正在运行的任务，安装器保留了原 Codex 进程，首次真实界面生效安排在下一次自然重启。正式发布前，我还会补一次重启后的真实截图验收。
这次经历让我印象最深的，不是 Codex 会写代码、会装服务。
而是：我们可以让 AI 不只生成代码，还能成为本地软件的改造伙伴。前提是人要把目标、边界、验收和恢复责任讲清楚。
一句“把弹窗删掉”，得到的可能只是一个脆弱补丁。
一份写清目标、非目标、安全门禁和回滚路径的任务合同，才有机会得到一个可以长期运行的工具。
这大概也是我越来越喜欢 Codex 的地方。
它不只是回答“怎么做”，还可以真的去读环境、做实现、跑验证，把所有东西交到你手上。
但最后决定什么可以改、什么不能碰、什么才算完成的人，仍然应该是你。
参考资料
说明：本文介绍的是个人在本机进行的非官方界面定制，不是 OpenAI 官方提供的“隐藏限额横幅”功能，也不会增加、恢复或绕过 Codex 使用额度。请根据自己的版本和风险承受能力决定是否使用。