概要
English summary: Add an opt-in, per-client feature that safely reapplies the last explicitly saved agent configuration after the CLIProxyAPI core becomes ready.
希望增加一个默认关闭的“内核就绪后自动重新应用智能体配置”功能。
用户可以为每个智能体客户端分别启用此功能。首次手动成功应用配置后，EasyCLIProxyAPI 保存该客户端的期望配置；以后应用启动或托管内核重启并确认就绪后，自动、安全且幂等地重新应用。
这项请求不是取消现有的“退出时恢复原始配置”机制，也不是要求让托管配置永久残留在客户端文件中。
当前行为与问题
目前 EasyCLIProxyAPI 退出时会恢复以下客户端的原始配置：
- Codex
- OpenCode
- OpenClaw
- Hermes
相关实现：
这对保护用户原始配置很有价值，但在系统重启或 EasyCLIProxyAPI 真正退出后，即使应用和内核都已自动启动，用户仍需进入“智能体配置”页面逐个点击“应用配置修改”。
当前前端只会在 WebView localStorage 中保存各客户端最近选择的模型：
它不是一个完整、可由后台可靠重放的期望配置，不能覆盖 Claude 模型映射、OAuth 配置方式、每客户端自动应用开关等信息。
建议行为
1. 总开关和每客户端开关
增加一个默认关闭的总开关，例如：
同时在每个客户端上增加独立开关。至少支持当前由智能体配置系统管理的：
- Claude Code
- Claude Desktop
- Codex
- OpenCode
- OpenClaw
- Hermes
只有用户明确启用的客户端才会自动应用，未选择的客户端不得被修改。
Pi 的 Provider 配置生命周期与其他客户端不同。如果纳入此功能，建议使用单独的“启动后检查并修复”开关；不要自动安装缺失的插件或 Provider。
2. 保存最后一次明确成功应用的配置
某客户端在用户手动点击“应用配置修改”并成功后，保存一份带版本号的期望配置，包括适用于该客户端的：
- 启用状态
- 模型 ID
- OAuth 配置方式
- Claude Code / Claude Desktop 的 Opus、Sonnet、Haiku 映射
- 1M context、最大上下文、自动压缩等客户端专属设置
- 配置 schema 版本和最后更新时间
该数据应保存在用户应用数据目录，而不是安装目录，并在软件升级时保留和迁移。
不要保存 API Key、OAuth Token、登录凭证或其他秘密。自动应用时应读取 EasyCLIProxyAPI 当前生效的端口和 API Key，以便端口、密钥或内核配置更新后使用新值。
3. 在内核真正就绪后执行
不要依赖固定延迟。
建议复用现有的内核状态或健康检查机制，确认 CLIProxyAPI 已可正常响应后再执行。如果应用启动时内核已经运行，也应能触发一次。
如果托管内核在同一应用会话中重启，可以在新的内核生命周期就绪后再次执行一次，以同步新的端口或 API Key。
这个功能本身不应隐式启动内核；是否自动启动内核仍由现有的“启动时运行内核”设置控制。
4. 幂等与防止事件循环
- 如果客户端当前配置已经等于期望配置，则直接报告
skipped/already-current，不要重复写文件。
- 每个内核生命周期最多自动执行一次。
- 配置文件监控事件不得再次触发同一轮自动应用，避免形成反馈循环。
- 多个客户端的写入应继续使用现有配置文件锁串行处理。
5. 失败隔离与可见结果
每个客户端独立执行：
- 一个客户端失败不能阻止其他已选择客户端。
- 缺少客户端、模型已不可用、配置文件无法解析或发生冲突时，跳过该客户端并显示原因。
- 不要静默回退到另一个模型。
- 界面显示每个客户端的
applied、already-current、skipped 或 failed 状态及时间。
- 提供“重试失败项”操作。
- 对内核暂未就绪的情况可做有限次数退避重试，但不要无限循环。
6. 无人值守写入的安全策略
自动应用属于无人值守操作，建议比手动操作采用更严格的安全策略：
- 复用现有事务式备份、原子/兼容写入和失败回滚流程。
- 仅修改 EasyCLIProxyAPI 管理的字段或区块，保留其他用户配置。
- 如果无法安全解析或合并，不要用全新配置覆盖原文件。
- 如果托管字段在上次应用后被外部修改且无法确认安全合并，应报告冲突并跳过。
- 应用中途失败时，只回滚当前客户端，不能影响已成功处理的其他客户端。
- 不自动安装缺失的客户端、CLI、插件或 Provider。
- 日志和错误信息中不得输出 API Key、OAuth Token 或其他凭证。
建议验收标准
使用场景
- 用户开启 EasyCLIProxyAPI 的系统登录自启动和内核启动。
- 用户为 Codex、OpenCode 等客户端选择模型并成功应用配置。
- 用户为这些客户端开启“启动后自动应用”。
- 用户退出应用或重启电脑。
- EasyCLIProxyAPI 与内核启动并就绪。
- 选中的客户端自动恢复到用户保存的期望配置，无需再次手动点击。
关联内容
- 已合并的 PR #14 实现的是 EasyCLIProxyAPI 登录时自动启动，并不负责重新应用客户端配置。
- 开放的安全加固 PR #121 提到密钥轮换后托管客户端可能需要重新应用配置；该功能也可以安全地使用当前密钥完成同步。
概要
希望增加一个默认关闭的“内核就绪后自动重新应用智能体配置”功能。
用户可以为每个智能体客户端分别启用此功能。首次手动成功应用配置后，EasyCLIProxyAPI 保存该客户端的期望配置；以后应用启动或托管内核重启并确认就绪后，自动、安全且幂等地重新应用。
这项请求不是取消现有的“退出时恢复原始配置”机制，也不是要求让托管配置永久残留在客户端文件中。
当前行为与问题
目前 EasyCLIProxyAPI 退出时会恢复以下客户端的原始配置：
相关实现：
agent_clients_restored_on_exitRunEvent::Exit中的配置恢复这对保护用户原始配置很有价值，但在系统重启或 EasyCLIProxyAPI 真正退出后，即使应用和内核都已自动启动，用户仍需进入“智能体配置”页面逐个点击“应用配置修改”。
当前前端只会在 WebView
localStorage中保存各客户端最近选择的模型：AGENT_MODEL_SELECTIONS_KEY它不是一个完整、可由后台可靠重放的期望配置，不能覆盖 Claude 模型映射、OAuth 配置方式、每客户端自动应用开关等信息。
建议行为
1. 总开关和每客户端开关
增加一个默认关闭的总开关，例如：
同时在每个客户端上增加独立开关。至少支持当前由智能体配置系统管理的：
只有用户明确启用的客户端才会自动应用，未选择的客户端不得被修改。
Pi 的 Provider 配置生命周期与其他客户端不同。如果纳入此功能，建议使用单独的“启动后检查并修复”开关；不要自动安装缺失的插件或 Provider。
2. 保存最后一次明确成功应用的配置
某客户端在用户手动点击“应用配置修改”并成功后，保存一份带版本号的期望配置，包括适用于该客户端的：
该数据应保存在用户应用数据目录，而不是安装目录，并在软件升级时保留和迁移。
不要保存 API Key、OAuth Token、登录凭证或其他秘密。自动应用时应读取 EasyCLIProxyAPI 当前生效的端口和 API Key，以便端口、密钥或内核配置更新后使用新值。
3. 在内核真正就绪后执行
不要依赖固定延迟。
建议复用现有的内核状态或健康检查机制，确认 CLIProxyAPI 已可正常响应后再执行。如果应用启动时内核已经运行，也应能触发一次。
如果托管内核在同一应用会话中重启，可以在新的内核生命周期就绪后再次执行一次，以同步新的端口或 API Key。
这个功能本身不应隐式启动内核；是否自动启动内核仍由现有的“启动时运行内核”设置控制。
4. 幂等与防止事件循环
skipped/already-current，不要重复写文件。5. 失败隔离与可见结果
每个客户端独立执行：
applied、already-current、skipped或failed状态及时间。6. 无人值守写入的安全策略
自动应用属于无人值守操作，建议比手动操作采用更严格的安全策略：
建议验收标准
使用场景
关联内容