### 问题背景
问题表现 ：在将Codex的供应商从 sub_lxapi 切换到 custom 后，所有旧对话（session）打开时报错：

Codex 无法加载 config.toml，因此此对话串无法继续。
请修复config.toml中的问题：Model provider `sub_lxapi` not found

### 问题的多层结构（关键认知）

这个问题比表面看起来复杂得多，配置存储在**四个不同层级**：

层级	位置	说明	是否关键
第1层：全局配置文件	config.toml	用户可见的配置文件	❌ 已正确修改但无效
第2层：Session文件	sessions/*.jsonl	每个对话的历史记录	✅ 需要修复
第3层：SQLite数据库（子目录）	sqlite/state_5.sqlite	状态数据库副本	⚠️ 修复了但未被读取
第4层：SQLite数据库（根目录）	state_5.sqlite	实际被Codex读取的数据库	✅这是关键！

**关键发现**：根目录下的数据库文件才是Codex实际读取的配置源，这是比环境变量更深一层的问题。

### 错误诊断过程

#### 最初尝试（无效）：
1. **修改全局config.toml** → `model_provider = "custom"` → ✅ 已正确但旧对话仍报错
2. **删除config.toml** → ❌ 无效，会自动重新生成
3. **清除所有缓存** → ❌ 无效，问题不在缓存

使用专用工具尝试（部分有效）：

工具准备 ：

- 安装Node.js 24+版本（必需）
- 安装codex-provider-sync工具：

npm install -g github:Dailin521/codex-provider-sync

工具执行 ：

codex-provider sync

4. **使用codex-provider-sync工具** → ⚠️ 报告修改0个文件，因为只检查了第1层

#### 深入排查：
- 检查环境变量：`CODEX_HOME` 设置正常
- 检查session文件：发现第2222行等多处还有旧配置
- 检查SQLite数据库：发现**根目录和子目录有重复的数据库实例**
- 根目录数据库：`state_5.sqlite` ← **Codex实际读取这个**
- 子目录数据库：`sqlite/state_5.sqlite` ← 这个不被读取

### 完整修复步骤

#### 步骤1：修复Session文件（JSONL）

使用Python脚本精确修复，避免编码问题：

```python
#!/usr/bin/env python3
"""
精确修复Codex session文件中的model_provider配置
"""
import json
from pathlib import Path

def fix_session_file(filepath, old_provider="sub_lxapi", new_provider="custom"):
    lines_fixed = 0
    temp_path = filepath.with_suffix('.jsonl.tmp')
    
    with open(filepath, 'r', encoding='utf-8') as f_in:
        with open(temp_path, 'w', encoding='utf-8', newline='') as f_out:
            for line in f_in:
                try:
                    data = json.loads(line)
                    if data.get('type') == 'session_meta':
                        payload = data.get('payload', {})
                        if payload.get('model_provider') == old_provider:
                            payload['model_provider'] = new_provider
                            data['payload'] = payload
                            lines_fixed += 1
                    f_out.write(json.dumps(data, ensure_ascii=False, separators=(',', ':')))
                    f_out.write('\n')
                except json.JSONDecodeError:
                    f_out.write(line)
    
    filepath.replace(temp_path)
    return lines_fixed

# 执行修复
sessions_dir = Path(r"用户名\.codex\sessions")
for filepath in sessions_dir.rglob("rollout-*.jsonl"):
    fix_session_file(filepath)
```

**路径**：`用户名\.codex\sessions\YYYY\MM\DD\rollout-*.jsonl`

#### 步骤2：更新SQLite数据库（关键！）

```bash
# 更新根目录数据库（这是Codex实际读取的）
sqlite3 "用户名\.codex\state_5.sqlite" \
  "UPDATE threads SET model_provider='custom' WHERE model_provider='sub_lxapi'"

# 同时更新子目录数据库（保持一致性）
sqlite3 "用户名\.codex\sqlite\state_5.sqlite" \
  "UPDATE threads SET model_provider='custom' WHERE model_provider='sub_lxapi'"
```

**关键路径**：
- `用户名\.codex\state_5.sqlite` ← **必须修复这个**
- `用户名\.codex\sqlite\state_5.sqlite`

#### 步骤3：验证修复

```bash
# 查询特定session的配置
sqlite3 "用户名\.codex\state_5.sqlite" \
  "SELECT id, model_provider FROM threads WHERE id='session-id'"

# 检查是否还有旧配置
sqlite3 "用户名\.codex\state_5.sqlite" \
  "SELECT COUNT(*) FROM threads WHERE model_provider='sub_lxapi'"
```

### 关键经验教训

#### 1. 删除config.toml和清除缓存**完全无效**

**原因**：
- `config.toml` 会自动重新生成，删除无意义
- 缓存不存储供应商配置，清除无效
- 问题根源在**数据库和session文件**，不在配置文件或缓存

#### 2. 环境变量不是根本问题

虽然检查了环境变量 `CODEX_HOME`，但真正的问题在于：
- **数据库实例的重复存储**
- Codex读取优先级：根目录数据库 > 子目录数据库 > config.toml

#### 3. 配置优先级（关键认知）

```
读取优先级（从高到低）：
1. 根目录SQLite数据库（state_5.sqlite） ← 最高优先级
2. Session文件中的session_meta记录
3. 子目录SQLite数据库（sqlite/state_5.sqlite）
4. 全局配置文件
5. 环境变量配置
```

#### 4. codex-provider-sync工具的局限性

该工具只检查session文件的**第一行session_meta**，忽略了：
- 后续的session_meta记录（如第2222行）
- SQLite数据库中的配置

### 最终解决方案总结

**必须修复的三个位置**：

1. ✅ **根目录SQLite数据库**：`用户名\.codex\state_5.sqlite`
   - 使用SQL UPDATE语句修改threads表
   
2. ✅ **Session文件（所有session_meta记录）**：`用户名\.codex\sessions\*.jsonl`
   - 使用Python脚本逐行修复，确保UTF-8编码
   
3. ⚠️ **子目录SQLite数据库**：`用户名\.codex\sqlite\state_5.sqlite`
   - 保持一致性，虽然可能不被读取

### 检查清单

修复完成后，请验证：
-  全局config.toml显示 `model_provider = "custom"`
-  SQLite查询显示无 `sub_lxapi` 配置
- Session文件中无 `sub_lxapi` 引用
- 重启Codex后旧对话正常打开

### 预防措施

1. 切换供应商前，备份重要对话
2. 使用专用工具而非手动删除文件
3. 理解配置的存储层级，不要只修改表面配置文件
4. 定期检查数据库状态，确保配置一致性

**核心结论**：这个问题比环境变量和配置文件更深一层，关键在于“SQLite数据库的配置缓存”。删除config.toml和清除缓存完全无效，必须直接修改数据库和session文件才能彻底解决。               如果实在无法解决，可以用trae_cn等AI工具打开以下路径的文件夹让AI帮你搞，记得备份!!!  记得备份!!!  记得备份!!!。

系统	config.toml	auth.json
Windows	C:\Users\用户名\.codex\	
macOS / Linux	~/.codex/