codex-history-recoverylisted

# Codex History Recovery 用于诊断和修复 Codex Desktop 历史记录可见性问题，尤其是 provider / model 元数据不一��导致的“旧对话还在本地，但侧边栏看不见”。优先使用随 skill 携带的脚本，因为 Codex Desktop 会从 `rollout-*.jsonl` 重建 `state_5.sqlite`；只改 SQLite 不可靠。 运行命令时，把 `<skill-dir>` 替换成当前 skill 的安装目录。常见目录： - `~/.agents/skills/codex-history-recovery` - `~/.codex/skills/codex-history-recovery` - 项目内 `.agents/skills/codex-history-recovery` ## 安全规则 - 不打印密钥、token、`.env` 值或对话正文。 - 除非用户明确要求迁移项目归属，否则不要修改 `cwd`。默认恢复必须保留每条对话原本所属项目目录。 - 删除归档历史时，绝不能删除 active history。只处理 SQLite 中 `threads.archived` 为 true 的记录、对应的归档 rollout JSONL，以及 `~/.codex/archived_sessions/` 下的孤儿文件。 - 归档删除是破坏性操作。必须先 dry-run，优先使用窄筛选，并依赖脚本自动备份后再 apply。 - 普通账号 / API / provider 切换恢复，只同步： - SQLite `threads.model_provider` - SQLite `threads.model` - JSONL `session_meta.payload.model_provider` - JSONL `turn_context.payload.model` - 如果用户只要求改 provider 或只改 model，使用窄参数，不要同时同步两个字段： - `--provider-only --from-provider <old> --provider <new>` - `--model-only --from-model <old> --model <new>` - 重写 rollout JSONL 必须保留文件 mtime；否则 Codex 可能把旧线程显示成最近更新。脚本在 sync 和 restore 中会保留 mtime。 - 写入前优先让用户完全退出 Codex Desktop。如果当前 agent 正在执行修复，无法关闭 Codex，则必须先说明 app 可能缓存或并发写入元数据，再使用 `--allow-running`。 - apply 前必须创建或依赖脚本自动备份。 ## 标准恢复流程 1. 只读检查状态： ```bash python3 <skill-dir>/scripts/codex_history_repair.py --json status ``` 2. 只用元数据计数解释可能原因： - provider / model mismatch：旧对话仍在本地，但被过滤掉。 - cwd filtering：对话仍属于原项目目录，这是预期行为。 - archived chats：只在归档视图可见。 - missing rollout paths：本地历史文件可能已删除或