[loopx-agent]

Automatic account handoff can miss an idle Codex consumer after its service label changes, or after it caches auth and closes its files. Discover the target home's App/helpers and recoverable user services by live process ownership, rather than a Chat label allowlist.

• Combine home file holders with identity-fenced Codex launch-environment reads; argv and environment values never enter diagnostics.
• Pause every related trusted LaunchAgent through its loaded plist, journal restoration before effects, and wait for captured old consumers to exit. Bound rescans and force escalation by the existing opt-ins and identities.
• Require a fresh live service process after restoration; retain ambiguous failures and preserve legacy journals. Add a read-only loopx-codex-accounts clients inventory; unmanaged owners continue to hold selection.
• Ship provider 0.12.6 with updated operator documentation. The renamed-service fix in fix(native-accounts): pause the renamed LoopX chat agent #7355 is subsumed by discovery; no fixed-name addition is required for future installations.

Validation: five provider Python smokes (including 22 operator tests), ten TypeScript policy tests, Python compilation/Ruff, committed-diff premerge checks and the bilingual RFC gate passed. The renamed-service counterexample fails on the baseline and passes here. On macOS, two isolated, credential-free live LaunchAgents with nonmatching plist filenames were discovered, stopped and restored to fresh PIDs through the production host coordinator, with one synthetic account transaction and clean recovery/cleanup.

The live launchd check uses a synthetic account owner: it does not claim a real credential swap, model request, or end-to-end business recovery. A filesystem/VM process without a proven restart owner remains a visible hold; no arbitrary CLI, VM or unrelated home is killed or replayed. Existing quota choice, cooldown, manual-selection and native account transaction ownership remain in place.

[loopx-agent]

Reviewer: model_agent; model=GPT-6; provider=OpenAI; self_reported

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机

启用原生账号自动切换和客户端重启的用户会遇到这个问题。例如后台 Chat 服务改名后，旧名单漏掉仍缓存旧认证的进程，换号持续受阻；新路径从目标认证目录的真实占用反查服务，停启后再检查新进程。隔离实测中两个不同名称的服务均被发现并恢复到新 PID，账号状态转换仅执行一次，恢复日志已清空。本次交付覆盖本机可核验的客户端和可恢复服务；真实账号换号、未知虚拟机内部状态和业务任务重放不在这次实测范围内。真实账号切换及已安装观察器的自然额度耗尽旅程仍需后续采用验收，无法证明归属的文件或虚拟机占用继续保留为明确等待。

改动思路

账号选择仍归 TypeScript 策略，凭据事务仍归现有原生账号管理器；进程与 launchd 操作只扩展现有 Python IO 适配器，避免再造凭据库或调度器。当前 PR 一起交付发现、退出、恢复、只读诊断与必要回归；运行时安装和自然换号继续由既有维护任务完成。固定名称补丁 #7355 可修一个安装，但改名、新 provider 或关闭文件后的认证缓存会再次漏掉。这里选择扩展同一个暂停/恢复 owner，并把旧进程身份和原 plist 路径保存在执行前的恢复意图中。它们是卸载后无法凭空重新发现的恢复依据，不是另一套手写服务目录。内核环境读取保持私有，公开诊断仅输出 PID、进程名和分类。

具体改动

已检查七个文件、+451/-80。native.py 连接原观察器与只读 clients 命令；native_processes.py 负责 Darwin 环境读取；native_host.py 扩展现有停启链路；smoke 覆盖动态服务和失败；两个版本清单统一为 0.12.6，NATIVE.md 更新行为说明。

关键代码讲解

• _consumer_agents（packages/loopx-codex-provider-routing/src/loopx_codex_provider_routing/native_host.py:387）：Map same-home Codex ownership to a trusted current-user job；fixed labels -> matching loaded path and frozen process tree。
• pause_chat_agents（packages/loopx-codex-provider-routing/src/loopx_codex_provider_routing/native_host.py:479）：Journal original service identity and path before unloading；digest-only label intent -> exact recoverable service intent。
• switch（packages/loopx-codex-provider-routing/src/loopx_codex_provider_routing/native_host.py:594）：Drain frozen consumers, switch once, restore；FD-only idle -> cached-auth discovery, actual helper exit and bounded rescan。
• resume_chat_agents（packages/loopx-codex-provider-routing/src/loopx_codex_provider_routing/native_host.py:529）：Restore every journaled job and validate fresh process；job loaded -> old process gone and new live PID。
• codex_home（packages/loopx-codex-provider-routing/src/loopx_codex_provider_routing/native_processes.py:14）：Private kernel launch-environment IO；No ps argv/env dumps; return only CODEX_HOME。

规范依据：packages/loopx-codex-provider-routing/NATIVE.md，不可变基线 b952235。以下编号是本评审对该已接受合同条款的映射，不是新增产品协议。

• NATIVE-IDLE：implemented；warm service / unmanaged CLI cases。
• NATIVE-CONSENT：implemented；disabled restart and ten policy cases。
• NATIVE-OWNERSHIP：implemented；PID reuse, other home, changed loaded plist and unknown owner cases。
• NATIVE-RECOVERY：implemented；bootout timeout, restore failure, changed plist and live-worker recovery cases。
• NATIVE-TRANSACTION：implemented；single transaction and real launchd readback; existing detached receipt path retained。

对主干的风险

最强反例是父进程或文件句柄消失了，旧子进程仍缓存认证。head 现在等待捕获身份对应的进程实际退出；正常终止后仍存活才按既有强退许可处理。不同 home、独立 CLI、仅打开目录的索引器、PID 复用、加载路径改变、超时和恢复失败均经过反例验证。无法归属的虚拟机保留等待，不能因发现一个 PID 就直接杀掉。旧格式恢复意图仍由同一 reader 消费，防止升级抹掉待恢复服务。

五项 Python package smoke、其中 22 项 operator 测试、十项 TypeScript policy 测试、Ruff、编译和精确提交 premerge 五项直接检查通过。premerge 自动目录没有选择包 smoke，因此包测试另行执行。真实 macOS 两服务停启核验使用隔离 home 与模拟账号事务，不是生产凭据换号验证。现有 restart/force 默认仍关闭，禁用路径没有信号或服务写操作。本 Goal 配置不等待 CI，本评审未查询远端 CI。

语义与 CI 对齐

沿用已有 native client、HostError 和恢复语义；没有新增 Core 账号策略、凭据写入器或 Goal 调度 owner。新增结构字段由原 worker 在 bootout 前产生，失败保留、恢复后删除；可读取旧日志直到其恢复义务排空。完整进程与服务发现不依赖 UI 展示数量。公开扫描已完成，原有源码 credential 字段的关键词提示不是泄漏。

我的整体评价

未发现阻塞性问题，结论 APPROVE，属于可独立评审、可回退的 justified_increment。长期持续运行与使用体验均改善：未来服务名不再依赖人工同步，也不增加确认轮次。检查 native.py 的命令行投影和 NATIVE.md，本次没有修改任何渲染页面，不需要新增页面截图。未验证的展示范围为 none。账号选择仍归 TypeScript 策略，凭据事务仍归现有原生账号管理器；进程与 launchd 操作只扩展现有 Python IO 适配器，避免再造凭据库或调度器。当前 PR 一起交付发现、退出、恢复、只读诊断与必要回归；运行时安装和自然换号继续由既有维护任务完成。最强剩余证据缺口是生产账号自然额度耗尽后的实际切换；这由既有维护任务继续，不将隔离进程实测写成生产业务已恢复。审查的完整 head 为 4968cf0。

English verdict: APPROVE — 4968cf0. Dynamic same-home consumer discovery reuses the existing native transaction/recovery owner. Renamed/multiple warm services, negative ownership/recovery cases, package/policy checks and isolated real launchd restart passed. Production credential cutover and opaque VM state remain outside this qualification.