Codex v0.99.0 版本将引入 /statusline 功能，能够更直观地展示当前的项目信息和模型状态，如下图所示。
在官方推出这个功能之前，我已经实现了类似的状态栏。本文不讨论如何实现状态栏本身，而是分享开发完成后，如何利用 Skills 快速同步上游代码的实践经验。
相比官方版本，我的实现在信息呈现上更加直观，功能也更加丰富 🤩。
链接🔗：https://github.com/Loongphy/codext[1]
此外，官方还未提供 Windows App，可以在该仓库的 Release[2] 下载编辑器版本，相关构建教程参见上一篇 OpenAI Codex App for Windows: 从零构建教程。
修改内容
由于这是个人定制化工具，我遵循以下原则进行改造：
- 跳过测试代码：测试运行耗时较长，暂不考虑
- 保持 TUI 结构稳定：尽量不破坏现有界面架构，降低后续合并代码的复杂度
- 快速同步上游：只关注功能实现，无需考虑代码审查和合并流程
基于上述原则，目前已实现以下功能：
1. 顶部状态栏
在编辑区域顶部增加状态栏，实时显示四类核心信息：
- 模型信息：当前使用的模型和推理等级
- 工作目录：当前所在文件夹路径
- Git 状态：当前分支名称及文件变更情况
- 用量统计：5 小时内的使用量和重置倒计时
2. 协作模式的独立配置
支持为 Plan 模式和 Code 模式分别配置模型参数：
[collaboration_modes.plan]
model = "gpt-5.2"
reasoning_effort = "xhigh"
[collaboration_modes.code]
model = "gpt-5.2-codex"
reasoning_effort = "xhigh"
3. 账号热切换
在新终端执行 codex login 后，其他终端会自动监听 auth.json 的变化并重新加载 TUI，无需手动退出重启。
为什么要二次开发
功能起源
Codex v0.90 版本正式推出了 Plan 模式和 Code 模式（默认）。这两种模式整体表现出色，Plan 模式还借鉴了 Cursor 的设计理念，会主动向用户提问以深入理解需求。
在开发大型功能或进行重构时，可以通过 Shift + Tab 切换到 Plan 模式。经过多轮对话确定最终方案后，再切回 Code 模式执行。
实践两天后我发现：对于前端开发，强烈建议严格遵循 Plan → Code 的工作流程。在 Plan 模式下与 Codex 充分交流，能够明确更多 UI/UX 细节，最终产出质量更高。
虽然 Vibe Coding 体验不错，但也暴露出一些问题。比如，Plan 和 Code 模式的模型与推理等级都是硬编码为 gpt-5.2-codex medium。这可以理解，毕竟功能还在实验阶段，内置提示词也在持续优化。但对于我这种习惯将推理等级设置为 xhigh 的用户来说，这显然不够理想。再加上使用体验不够便捷，于是开启了二次开发之路。
最终效果如下：
核心诉求
二次开发的目标很简单：提升效率，优化开发体验。
- 实时用量展示：频繁使用
/status查看模型和用量很繁琐，需要一个像上下文用量那样直观的实时视图 - Git 分支提示：多分支并行开发时，需要明确当前所在分支，避免在错误分支上提出重复需求
- 模型配置确认：需要随时确认当前使用的模型和推理等级配置
……
你也许也有自己的痛点。既然现在的 Coding Agent 已经足够强大，为什么不直接打造一个更符合个人习惯的定制版本呢？
当然，二次开发也意味着取舍：一旦开始，你需要持续追赶官方的最新版本，每次发版都要同步并合并代码。
同步上游的工作流程
为了避免复杂的代码冲突，我采用了以下流程：
- 基于特定版本创建功能分支（如
feat/v0.94），开发并验证功能后，将改动记录到CHANGED.md文件 - 同步官方最新版本：执行
git fetch upstream tags，获取最新 tag（如rust-0.98.0） - 基于最新版本重建分支（如
feat/rust-0.98），从旧分支复制CHANGED.md，根据记录的改动重新开发 - 验收功能完成更新
这套流程的核心思路是：每次都基于最新代码从零开始，完全避免处理上游代码冲突。跳过测试代码编写，快速交付，完成迭代。
Skills 分享
基于上述流程，我整理了一套 Skills，你也可以根据自己的需求进行改造。
