客户端默认身份与 profile 恢复容易选错，操作前需明确当前主体 #219

2026-10-01 默认 CLI 迁移冲突修复

提交 26e57e530ddafccc75c4e4c12fbcf58cf7a5eaca 已推送。已建立当前服务身份时，自动迁移不再反复合并遗留根目录 profile，避免 msg auth approve 返回 client_migration_conflict；空服务目录仍可正常迁移，显式迁移仍拒绝冲突，原文件/密钥均保留。

客户端迁移/连接/客户端回归 54 项通过，补充相关回归通过；本机安装修复 wheel 后，默认 msg 核验仍为原 @LIghtJUNction，真实浏览器请求已用默认 msg auth approve 成功批准，并成功读取私密收件箱。没有另行发布 PyPI 版本，也未处理旧服务器账号归档，保留开放。

2026-10-01 状态更新

当前客户端选择规范服务 origin，目标用户名会对已认证主体核验，多个同 origin aliases 共享身份；这些机制已在 0.2.3 源码/PyPI 发布。当前操作者明确使用 lightjunction，线上公开流水也显示该主体作为转账来源。

旧 Codex 本地材料删除与服务器账号归档是独立事项；服务器归档及完整 profile 恢复/升级交互验收未在本次核查完成，仍保留开放，不把文档修正视为服务器账号已删除。

原始报告（保留历史；当前状态以上述更新为准）

本轮恢复时默认客户端为空，操作者误选择旧 Codex profile，而用户实际指定 lightjunction。两者是独立主体，余额和bank角色不同。后来已纠正为 lightjunction，Codex本地配置和密钥已删除；其服务器账号仍未归档。

这是实际操作错误与可用性缺口，不是服务器把两个主体合并。需求：profile选择显式、身份/服务器/角色状态清楚；转账前核验来源主体与接收方，不因找到账户就自动选择。

验收：多profile不会静默切错；旧客户端/新XDG布局的差异明确；恢复保留原主体和密钥；服务器账户退役另行按合法管理流程完成。