分享Codex桌面端历史污染修复Prompt，涉及SQLite安全操作。
遇到Codex桌面端更新后左侧历史记录被“子智能体会话”刷屏污染的兄弟，可以试试这个安全无损的修复Prompt。
📌 Bug 根源：
Codex最近更新后开放了线程级访问权限，部分第三方增强插件（如 Codex++ / Codex Deck）在历史同步时没有正确识别和过滤 thread_source='subagent'，导致后台衍生出来的各种子任务被一窝蜂同步进了左侧主历史目录。
🛠️ 一键安全修复方法：
在 Codex里新建一个空对话，直接复制粘贴下面这段带有 SQLite在线一致性备份与严格无损校验的指令给Codex 即可：👇
我遇到了 Codex 桌面端历史目录污染问题：子智能体会话被当成普通任务显示在左侧对话历史中。可能与 Codex++ / Codex Deck 的 Provider Sync 或“历史会话恢复”有关。请直接调查并安全修复，但严格遵守以下要求： 1. 先只读诊断，不要根据固定文件名盲目修改。定位 Codex Home（通常是 ~/.codex），通过表结构找到： - 含 threads 表及 thread_source 字段的当前规范线程数据库； - 含 local_thread_catalog 表的左侧历史目录数据库。 常见位置是 state_5.sqlite 和 sqlite/codex-dev.db，但必须实际核实。 2. 统计规范线程中 thread_source='subagent' 和 'user' 的数量，并通过 thread_id 关联 local_thread_catalog，确认确实有子智能体进入普通历史。若缺少 thread_source 字段、表结构不同或无法可靠关联，立即停止，不要猜测。 3. 检查 Codex++ / Codex Deck 是否运行，以及 Provider Sync、历史修复是否仍启用。不要读取或输出 API Key。修复期间不要再次运行第三方历史同步。 4. 即使官方 Codex 正在运行，也可以先测试 SQLite 写锁：执行 BEGIN IMMEDIATE 后立即 ROLLBACK。若无法取得锁，不要强杀进程，提示我完全退出 Codex 后再继续。 5. 在当前工作目录中新建带时间戳的备份子目录，不得放在系统盘根目录、其他磁盘根目录或 ~/.codex 内。若 Codex 正在运行，必须使用 SQLite Online Backup API 创建一致性备份，不要直接复制带 WAL 的数据库文件。至少备份规范线程库和目录库，并对备份执行 integrity_check。 6. 备份验证成功后，用单一事务修复： - 从规范 threads 表取得 thread_source='subagent' 的线程 ID； - 只删除 local_thread_catalog 中 thread_id 属于这些 ID 的目录索引； - 不得删除或更新 threads 表中的子智能体记录； - 不得删除 rollout、sessions、archived_sessions、thread_spawn_edges 或其他真实会话数据； - 不得根据 local_thread_catalog 自身可能为空或错误的 thread_source 字段扩大删除范围； - 提交前断言所有非目标目录行完全未变化。 7. 检查 local_thread_catalog_sync_state。只有其 watermark_updated_at 或 observation_sequence 不再等于对应 host 剩余目录行的最大值时，才定向校准；不要盲目重建目录或修改其他元数据。 8. 提交后验证并报告： - 数据库 integrity_check 和 foreign_key_check； - 删除前后目录数量； - 左侧目录中剩余的子智能体数量必须为 0； - 规范 threads 中子智能体数量必须与备份前一致； - 所有子智能体 rollout 文件仍然存在； - 短暂复查后第三方工具没有立即重新写回。 9. 完成后让我完全退出并直接启动官方 Codex，不要从 Codex++ / Codex Deck 启动。官方子智能体应通过 Subagents 的 Active/Done 或主任务活动入口查看： https://t.co/pa60RJJfYI 10. 在我明确回复“重启后正常”之前保留备份。确认正常后，只删除本次创建且经过精确路径和内容校验的备份目录，不得使用指向工作区根目录的递归删除。
跑完后重启官方Codex就能恢复干净的主目录了。
📌 Bug 根源：
Codex最近更新后开放了线程级访问权限，部分第三方增强插件（如 Codex++ / Codex Deck）在历史同步时没有正确识别和过滤 thread_source='subagent'，导致后台衍生出来的各种子任务被一窝蜂同步进了左侧主历史目录。
🛠️ 一键安全修复方法：
在 Codex里新建一个空对话，直接复制粘贴下面这段带有 SQLite在线一致性备份与严格无损校验的指令给Codex 即可：👇
我遇到了 Codex 桌面端历史目录污染问题：子智能体会话被当成普通任务显示在左侧对话历史中。可能与 Codex++ / Codex Deck 的 Provider Sync 或“历史会话恢复”有关。请直接调查并安全修复，但严格遵守以下要求： 1. 先只读诊断，不要根据固定文件名盲目修改。定位 Codex Home（通常是 ~/.codex），通过表结构找到： - 含 threads 表及 thread_source 字段的当前规范线程数据库； - 含 local_thread_catalog 表的左侧历史目录数据库。 常见位置是 state_5.sqlite 和 sqlite/codex-dev.db，但必须实际核实。 2. 统计规范线程中 thread_source='subagent' 和 'user' 的数量，并通过 thread_id 关联 local_thread_catalog，确认确实有子智能体进入普通历史。若缺少 thread_source 字段、表结构不同或无法可靠关联，立即停止，不要猜测。 3. 检查 Codex++ / Codex Deck 是否运行，以及 Provider Sync、历史修复是否仍启用。不要读取或输出 API Key。修复期间不要再次运行第三方历史同步。 4. 即使官方 Codex 正在运行，也可以先测试 SQLite 写锁：执行 BEGIN IMMEDIATE 后立即 ROLLBACK。若无法取得锁，不要强杀进程，提示我完全退出 Codex 后再继续。 5. 在当前工作目录中新建带时间戳的备份子目录，不得放在系统盘根目录、其他磁盘根目录或 ~/.codex 内。若 Codex 正在运行，必须使用 SQLite Online Backup API 创建一致性备份，不要直接复制带 WAL 的数据库文件。至少备份规范线程库和目录库，并对备份执行 integrity_check。 6. 备份验证成功后，用单一事务修复： - 从规范 threads 表取得 thread_source='subagent' 的线程 ID； - 只删除 local_thread_catalog 中 thread_id 属于这些 ID 的目录索引； - 不得删除或更新 threads 表中的子智能体记录； - 不得删除 rollout、sessions、archived_sessions、thread_spawn_edges 或其他真实会话数据； - 不得根据 local_thread_catalog 自身可能为空或错误的 thread_source 字段扩大删除范围； - 提交前断言所有非目标目录行完全未变化。 7. 检查 local_thread_catalog_sync_state。只有其 watermark_updated_at 或 observation_sequence 不再等于对应 host 剩余目录行的最大值时，才定向校准；不要盲目重建目录或修改其他元数据。 8. 提交后验证并报告： - 数据库 integrity_check 和 foreign_key_check； - 删除前后目录数量； - 左侧目录中剩余的子智能体数量必须为 0； - 规范 threads 中子智能体数量必须与备份前一致； - 所有子智能体 rollout 文件仍然存在； - 短暂复查后第三方工具没有立即重新写回。 9. 完成后让我完全退出并直接启动官方 Codex，不要从 Codex++ / Codex Deck 启动。官方子智能体应通过 Subagents 的 Active/Done 或主任务活动入口查看： https://t.co/pa60RJJfYI 10. 在我明确回复“重启后正常”之前保留备份。确认正常后，只删除本次创建且经过精确路径和内容校验的备份目录，不得使用指向工作区根目录的递归删除。
跑完后重启官方Codex就能恢复干净的主目录了。