[130040167]

历史聚合会话记录了 codex_plus_managed，但当前配置只有活动供应商时，主进程原生恢复会提示找不到供应商。部分旧迁移只修改 SQLite 索引，rollout 的 session_meta 仍保存原身份。

• 按历史需要补充同名兼容 provider，传输跟随当前生效供应商，保留默认 provider 和历史身份。官方 OpenAI 配置重建认证选项，活动 provider 无法解析时删除旧兼容表，避免残留端口和凭据。
• 启动、激活已有应用时的修复遵守 relay_profiles_enabled 与网关模式，且仅查 SQLite 索引；通用配置写入和代理同步只维护已有兼容表。显式应用供应商（包括管理器的重启与多开启动）且兼容表缺失时，才读取索引引用的 rollout 前八行。没有引入缓存；旧索引已改名而仅 rollout 保留内部身份时，需要重新应用供应商。
• 供应商切换已写入配置之后，兼容表的独立修复若失败，只记录诊断，不再把已生效的切换误报为失败；失败时不声称历史会话已恢复。
• managed_rollout_path 内同时规范化 home 与 rollout，兼容 Windows namespaced / 8.3 路径，并保持当前 home 的目录边界。补充 Unix 符号链接与 macOS /var、/private/var 回归。
• 兼容配置负责未经过渲染入口的原生恢复；prepareCodexManagedSessionConnection 继续负责渲染层会话连接覆盖；provider_sync 仍按自己的开关迁移历史。分工详见 docs/managed-session-provider.md。

Windows 验证：

• managed-provider 单测 10 项、relay_config 配置回归 226 项（含写入后兼容修复失败回归）、launcher 激活路径 4 项通过。
• 可选原生 app-server 回归已实际执行通过：缺少 provider 时原生 thread/resume 失败，生产修复函数补表后恢复成功，重启后按 ID 再次恢复成功，历史用户及助手消息完整。
• 原生回归仅使用临时目录和合成历史，清空继承环境，不使用真实 auth；限定 initialize、thread/resume、thread/read，不发送 turn/start，退出与断言失败均清理本次进程树。
• 前端 TypeScript 检查、生产构建、管理器 debug 构建及 git diff --check 通过；最终构建的隔离管理器启动就绪，测试进程和端口收尾通过，原有实例身份未变。

可选原生回归需要显式设置 CODEX_PLUS_TEST_CODEX_BIN，默认忽略。上述原生恢复验证覆盖官方 provider 配置和本地历史读取，不验证真实登录鉴权或生成。macOS 特有回归尚待在该平台执行。

[130040167]

Windows 检查中两项历史路径识别失败已定位并修复：rollout 被规范化为长路径，但 home 可能仍是 RUNNER~1 等短路径，边界比较误判。现在先将 home 一并规范化，保持目录外记录的拒绝边界。

已补真实 8.3 home 别名回归，修复前可复现失败，修复后 managed_session_provider 的 8 项测试全部通过。分支包含 main b70bcf26；前端和管理器 debug 构建、git diff --check 通过。没有将 Windows 失败归因于构建环境，也未改动会话身份或历史文件来绕过检查。

最终构建的独立原生管理器启动检查通过，测试进程和端口清理完成，原有实例身份未变。未发送模型请求，未将启动检查表述为真实历史会话生成验收。

[BigPizzaV3]

感谢修复！在 macOS 上 managed_session_provider_ignores_rollouts_outside_home_and_unrelated_metadata 和 ..._keeps_legacy_rollout_identity_... 两个用例失败：managed_rollout_path 只 canonicalize 了 rollout 路径，没有 canonicalize home，/var 和 /private/var 前缀对不上，建议在函数内也规范化 home。另外有几点想请调整：

1. 没有受管会话时 managed_session_provider_needed 会逐个读取全部 rollout，而它在启动、激活和每次写配置时都会执行，会话多的用户开销很大。建议缓存结果（例如按 state DB 的 mtime 加会话数），或只在应用聚合配置、切换供应商时执行；
2. 启动和激活时的修复请遵守 relay_profiles_enabled 和网关模式，不要改动未开启配置接管的用户的 config.toml；
3. 别名表会完整复制当前供应商的凭据；model_provider 无法解析时请移除旧的 codex_plus_managed 表，不要保留旧端口和凭据；
4. 能否说明一下这个补丁和渲染层 prepareCodexManagedSessionConnection、provider_sync 改写 session_meta 的分工，再补一个官方登录模式下原生恢复的用例？谢谢！

[130040167]

已补齐本轮边界调整：启动和激活只查 SQLite 索引，通用写配置不再扫描 rollout；旧 rollout 检测限定到显式应用或切换供应商且兼容表缺失时。接管关闭与网关模式直接跳过启动修复；无法解析活动 provider 时移除旧兼容表。

managed_rollout_path 在 c192 已同时 canonicalize home 和 rollout，本轮增加 Unix 符号链接及 macOS /var、/private/var 回归；Windows 的 8.3 回归继续保留。macOS 特有用例未在 Windows 上冒充实跑。

另补实际执行的原生 app-server 测试：先复现缺少 codex_plus_managed 的 thread/resume 错误，再调用生产配置修复，确认恢复合成历史及重启后按 ID 恢复均通过。只使用官方 provider 配置和隔离目录，不使用真实登录凭据、不发送 turn/start，因此不宣称真实鉴权或生成验收。

managed-provider 单测 10 项、配置回归 225 项、launcher 激活路径 4 项及新增原生回归 1 项通过；前端检查、生产构建和管理器 debug 构建通过。三个修复层的职责和扫描边界已写入 docs/managed-session-provider.md。

[BigPizzaV3]

感谢调整，macOS 上相关测试都通过了，四点也都看到了。还有两处小收尾：

1. apply_relay_profile_to_home_with_switch_rules_and_proxy_port 里修复兼容表用了 ?，此时 config.toml 已经写好，修复失败会让这次切换报错、但配置其实已经变了，建议改为写诊断日志、不中断应用；
2. PR 描述里「启动或激活已有应用时修复」请按现在只查索引、只在应用供应商时扫 rollout 的行为更新一下。

另外，管理器里的「重启 Codex」和每次启动多开实例也会走应用流程，没有命中时仍会扫一遍全部 rollout，不阻塞合入，可以之后再看。谢谢！

[130040167]

供应商配置写入成功后，兼容 provider 的独立修复失败现在记录 relay_config.managed_session_provider_repair_failed 诊断并返回原应用结果，避免配置已经改变却把切换报告为失败。新增真实文件系统故障回归：初次写入成功，后置修复所需的备份目录被普通文件阻挡，断言切换成功且失败原因已记录；修复前可复现错误返回。

正文已更新扫描边界：启动、激活只查 SQLite；通用写配置仅维护已有兼容表；显式应用供应商且兼容表缺失时才扫描索引引用的 rollout，也包括管理器重启与多开启动。尚未增加未命中结果缓存。

Windows relay_config:: 226 项通过，前端检查、生产构建、管理器 debug 构建及差异检查通过。最终提交构建的隔离管理器启动就绪，测试进程和端口清理完成，原有实例身份未变；本次启动验收不替代历史会话鉴权或生成验收。