我们在 macOS 用户登录后的 botmux 自动启动场景中遇到稳定性问题：服务表面已启动，但用户发送首条消息时会报“Codex App 会话启动失败：worker 在就绪前退出（exit code: 1）”；人工执行一次 botmux restart 后恢复。我们的目标是获得长期、受官方支持、无需人工重启且不二次修改 botmux 源码的解决方案。
运行环境与已确认事实
当前 botmux 版本：3.18.11。
当前官方 LaunchAgent：~/Library/LaunchAgents/com.botmux.daemon.plist。
官方形态的启动入口是原生二进制执行 botmux start，并使用 RunAtLoad=true。
botmux status 在运行态可显示 supervisor 与 worker online；但在问题发生后，首条真实 Feishu 消息仍可能在 worker ready 前失败，人工 botmux restart 后恢复。
session store 中曾出现 status=active 且 backendType=tmux 的会话记录，但对应 tmux server 已不存在；清理这类残留记录并重启后，服务可以恢复。
旧日志中还存在历史版本的 node: No such file or directory / PM2 127；我们不把它当作当前版本根因，除非官方认为两者相关。
当前 botmux status 曾提示存在 legacy PM2 daemon；我们会单独按官方迁移路径处理，不希望用外部脚本掩盖这一变量。
我们已排除的非长期方案
我们没有修改源码。我们评估过把 LaunchAgent 改为 wrapper、或用双 LaunchAgent + marker 先清理会话再启动，但发现官方 botmux start/restart 会刷新 com.botmux.daemon.plist 回官方形态。因此：
直接改 ProgramArguments 指向 wrapper 会在正常 start/restart 后失效；
依赖 WatchPaths / StartInterval 的双 agent 编排无法得到 launchd 对“严格先后、精确一次消费”的保证；
定时或登录后无条件 restart 只是在掩盖问题，会制造启动窗口和额外竞争。
我们不希望采用任何会与官方 autostart 机制对抗的长期绕行。
请求官方提供的长期解决方案
请确认并提供以下任一受支持能力（优先级从高到低）：
官方启动前恢复钩子或配置项：在 daemon/worker 接收首条消息前，安全地执行 session backend 健康校验与 stale-session reconciliation；需要是官方持久配置，不能被 botmux start/restart 覆盖。
官方内置修复：启动时检测“session store 标为 active/tmux、但 tmux server 不存在”的不一致状态，并将对应会话以可审计方式关闭或恢复，避免首条消息创建 worker 后立即退出。
官方诊断与恢复接口：提供稳定 CLI/API，例如只读检查、受支持的 stale-session repair、preflight healthcheck，以及结构化错误码/日志字段，让运维可以准确区分 tmux 残留、worker 启动、Node/PM2 环境和凭证网络问题。
如以上能力已有，请给出对应版本、配置键、命令、启动顺序语义、幂等性说明、回滚方式及 macOS LaunchAgent 的官方兼容性说明。
安全与数据完整性要求
自动恢复只能处理明确失效的会话：backend 为 tmux、记录为 active、且 tmux server/目标 session 确认不存在。
不得关闭仍有存活 tmux server 的正常会话。
恢复前应保留 session-store 备份或等价可回溯记录；日志应包含处理数量、会话标识、判定原因、版本和时间。
不能要求用户手动修改私有运行目录、反复覆写官方 plist，或通过无条件 restart 维持可用性。
不能影响 MCP、插件、凭证、任务调度或其他 bot 配置。
建议官方验收标准
从真实重启/用户登录开始，官方 autostart 完成后不执行人工 botmux restart。
连续发送至少两条真实 Feishu 消息；第一条即可成功创建 Codex App 会话，日志中无“worker 在就绪前退出（exit code: 1）”。
botmux status、worker/session 状态、tmux 后端状态均一致；不存在 legacy PM2 的并发消费或 session-store 争用告警。
执行官方 botmux start/restart 后，修复配置或恢复能力仍然存在并继续生效。
故意构造或保留一条 stale active/tmux 记录时，官方机制只处理该失效记录，并有备份与审计；正常活跃会话不受影响。
请官方先确认：这是否已知问题、推荐的正式修复路径是什么、预计在哪个版本或以何种配置交付。我们可在脱敏前提下补充启动时间线、相关日志片段和 session-store 状态摘要。
我们在 macOS 用户登录后的 botmux 自动启动场景中遇到稳定性问题：服务表面已启动，但用户发送首条消息时会报“Codex App 会话启动失败：worker 在就绪前退出（exit code: 1）”；人工执行一次 botmux restart 后恢复。我们的目标是获得长期、受官方支持、无需人工重启且不二次修改 botmux 源码的解决方案。
运行环境与已确认事实
当前 botmux 版本：3.18.11。
当前官方 LaunchAgent：~/Library/LaunchAgents/com.botmux.daemon.plist。
官方形态的启动入口是原生二进制执行 botmux start，并使用 RunAtLoad=true。
botmux status 在运行态可显示 supervisor 与 worker online；但在问题发生后，首条真实 Feishu 消息仍可能在 worker ready 前失败，人工 botmux restart 后恢复。
session store 中曾出现 status=active 且 backendType=tmux 的会话记录，但对应 tmux server 已不存在；清理这类残留记录并重启后，服务可以恢复。
旧日志中还存在历史版本的 node: No such file or directory / PM2 127；我们不把它当作当前版本根因，除非官方认为两者相关。
当前 botmux status 曾提示存在 legacy PM2 daemon；我们会单独按官方迁移路径处理，不希望用外部脚本掩盖这一变量。
我们已排除的非长期方案
我们没有修改源码。我们评估过把 LaunchAgent 改为 wrapper、或用双 LaunchAgent + marker 先清理会话再启动，但发现官方 botmux start/restart 会刷新 com.botmux.daemon.plist 回官方形态。因此：
直接改 ProgramArguments 指向 wrapper 会在正常 start/restart 后失效；
依赖 WatchPaths / StartInterval 的双 agent 编排无法得到 launchd 对“严格先后、精确一次消费”的保证；
定时或登录后无条件 restart 只是在掩盖问题，会制造启动窗口和额外竞争。
我们不希望采用任何会与官方 autostart 机制对抗的长期绕行。
请求官方提供的长期解决方案
请确认并提供以下任一受支持能力（优先级从高到低）：
官方启动前恢复钩子或配置项：在 daemon/worker 接收首条消息前，安全地执行 session backend 健康校验与 stale-session reconciliation；需要是官方持久配置，不能被 botmux start/restart 覆盖。
官方内置修复：启动时检测“session store 标为 active/tmux、但 tmux server 不存在”的不一致状态，并将对应会话以可审计方式关闭或恢复，避免首条消息创建 worker 后立即退出。
官方诊断与恢复接口：提供稳定 CLI/API，例如只读检查、受支持的 stale-session repair、preflight healthcheck，以及结构化错误码/日志字段，让运维可以准确区分 tmux 残留、worker 启动、Node/PM2 环境和凭证网络问题。
如以上能力已有，请给出对应版本、配置键、命令、启动顺序语义、幂等性说明、回滚方式及 macOS LaunchAgent 的官方兼容性说明。
安全与数据完整性要求
自动恢复只能处理明确失效的会话：backend 为 tmux、记录为 active、且 tmux server/目标 session 确认不存在。
不得关闭仍有存活 tmux server 的正常会话。
恢复前应保留 session-store 备份或等价可回溯记录；日志应包含处理数量、会话标识、判定原因、版本和时间。
不能要求用户手动修改私有运行目录、反复覆写官方 plist，或通过无条件 restart 维持可用性。
不能影响 MCP、插件、凭证、任务调度或其他 bot 配置。
建议官方验收标准
从真实重启/用户登录开始，官方 autostart 完成后不执行人工 botmux restart。
连续发送至少两条真实 Feishu 消息；第一条即可成功创建 Codex App 会话，日志中无“worker 在就绪前退出（exit code: 1）”。
botmux status、worker/session 状态、tmux 后端状态均一致；不存在 legacy PM2 的并发消费或 session-store 争用告警。
执行官方 botmux start/restart 后，修复配置或恢复能力仍然存在并继续生效。
故意构造或保留一条 stale active/tmux 记录时，官方机制只处理该失效记录，并有备份与审计；正常活跃会话不受影响。
请官方先确认：这是否已知问题、推荐的正式修复路径是什么、预计在哪个版本或以何种配置交付。我们可在脱敏前提下补充启动时间线、相关日志片段和 session-store 状态摘要。