在日常工作中，无论是制作视频、开发产品项目，还是做技术调研，我几乎都在 Codex 里面完成。重度使用带来的一个直接后果，就是左侧边栏里堆积了大量对话话题，而且经常有三四个项目同时并行推进。
当话题数量变多之后，Codex 原生的命名机制就成了很大的阻碍。它默认只会根据你发送的第一句话生成标题，而且后续不会随着对话内容的深入自动更新。比如我新建话题时随手发了一句「你好」，标题就会被命名为「回应中文的问候」；哪怕下一句我就开始让它排查邮箱验证码提前过期的问题，侧边栏里显示的依然是「回应中文的问候」。过两天再想从几十个话题里找回那次排查记录，就只能挨个点开翻看。
为了解决这个问题，我开发并开源了一个 Codex 插件 oil-codex-title，用来在每轮对话结束后自动维护话题标题，并定期清理长期闲置的旧话题。
用「类别图标 + 具体对象 | 当前目标」统一标题格式
一个好找的话题标题，应该让人扫一眼侧边栏就知道它属于哪类工作、在操作哪个对象、当前推进到了哪一步。因此我在插件里把自动命名的格式固定为三段结构：
最前面是一个代表工作类别的 Emoji 图标，插件内置了内容（🎬）、开发（🧩）、调研（🔍）、设计（🎨）、文档（📝）、日程（📅）、环境（⚙️）和讨论（💬）八种分类。
图标后面紧跟着「具体对象」与「当前目标」，中间用竖线分隔。之所以要单独标出具体对象，是因为我有时会在桌面或大工作区目录下直接开启会话，再去修改里面的某一个子项目或单文件；如果外层项目目录本身已经有明确名称，插件就会自动省略重复的项目名，直接写模块对象（例如「🧩 邮箱验证码 | 过期排查」或「🎬 视频制作 | 导出视频」）。同时，插件也保留了手动控制机制，支持随时固定或解锁某个标题，以及暂停自动命名。
通过 Stop Hook 与 Luna 模型在后台无感改名
在实现机制上，这个插件完全在后台异步运行，不会打断或污染原有的对话上下文。
Codex 支持配置生命周期 Hook。每当一轮对话结束、AI 完成信息总结时，就会自动触发结束通知（Stop Hook），唤起插件里的 Python 脚本。脚本会摘取最近 3 到 5 轮的对话内容，并结合最初的任务目标，在后台单独通过 Codex CLI 调用 GPT 5.6 Luna 模型（开启 low 最低思考程度与 fast 模式），由它判断是否需要更新标题以及生成什么新名称。拿到新标题后，脚本直接调用 Codex 内置 App Server 的官方接口修改当前话题名称。
之所以选择 GPT 5.6 Luna 搭配 low 思考程度，主要是看重它的响应速度和成本控制：Luna 本身价格很便宜，而改名任务绝大部分是输入上下文，模型只需要输出短短一行标题，消耗的输出 Token 极少。
即便如此，插件还是在调用模型前加了一层必要性检查：如果当前对话内容已经处理过、标题已被用户手动固定，或者自动命名处于暂停状态，脚本会直接跳过，不发起任何模型请求；如果在模型生成候选标题的几秒钟内，用户又在原话题里发起了新对话，写入前也会自动丢弃旧候选，防止覆盖最新进展。
定时归档长期闲置的话题
除了实时更新标题，侧边栏越用越乱的另一个原因是大量早就做完的话题一直挂在列表里。为此，插件在安装时会自动创建一个每天早上 10 点执行的定时清理任务。
定时归档分为两档规则：
- 14 天未聊的话题：先由程序筛选出超过 14 天没有新消息的会话，再交给
Luna模型根据上下文判断里面的工作是否已经明确完成。如果任务已经收尾且没有待办事项，就自动帮我们归档；如果还在进行中或被置顶，则继续保留。 - 30 天未聊的话题：只要超过 30 天没有任何对话且无明确待办，程序就会直接执行自动归档，不再额外调用模型去判断。已经归档的话题后续也不会重复评估。
实际使用效果与安装方式
用上这套命名和归档规则之后，我的 Codex 侧边栏清爽了很多。
像上图展示的 oil-social-media 和 oil-video 目录，平时同时跑着视频发布 Skill 修复、Git 教程视频上线、落地页还原方法沉淀和镜头转场优化等多个任务。现在每个话题前面都有清晰的类别图标，操作对象和当前动作一目了然，跨项目来回切换时再也不用靠猜去翻历史记录了。
如果你在日常使用 Codex 时也有多话题难以管理的困扰，可以直接在 GitHub 搜索 oil-oil/oil-codex-title，或者把仓库路径发给 Codex，对它说一句「帮我安装这个插件」即可自动完成配置。