fix(usage): prevent CI and synthetic profiles from reporting installations - #5272
Conversation
cocolord
left a comment
cocolord
left a comment
There was a problem hiding this comment.
REQUEST_CHANGES — [P1] exact head bda6b0acadf7cada195c4dc020e84123d175e585 的 telemetry 隔离机制本身有效，但遗漏了既有 native profile fail-closed contract test 的同步：benchmark/tests/test_native_codex_profile.py::test_native_codex_app_server_shell_policy_is_explicit_and_fail_closed 在 base 为 12/12 通过，当前 head 为 1 failed / 11 passed。
动机
这个 PR 修复的是一个真实且不可事后可靠清洗的数据质量问题：native benchmark profile、release qualification、pytest 或 canary 在重建最小环境时，可能丢掉父进程的 CI / opt-out 信号；fresh HOME 随后会生成随机 installation ID，并把合成运行计入真实 adoption。把 repository-owned synthetic run 在创建子进程时显式标成不采集，可以避免持续污染指标，同时不需要按 OS、安装渠道或随机 ID 猜测来源，也不改变普通用户的 consent 与 usage-ping 行为。
同一输入的 base/head 反事实证明收益明确：父环境显式设置 LOOPX_USAGE_PING=1，真实 child CLI 连续执行两次并连接可丢弃的本地 collector；base 创建 reporting installation 并发送 1 次，head 的发送状态被 LOOPX_USAGE_PING 阻断且 0 请求。这个差异直接命中 PR 目标，不只是环境字典断言。
改动思路
实现继续复用 TypeScript usage owner 的 blockedBy 规则，没有增加第二套 telemetry policy。Python 只在自己拥有的 synthetic launch boundary 设置 LOOPX_USAGE_PING=0：formal installer、profile runtime、Codex Agent tool shell、canary subprocess 和 native release qualification；pytest 与两个 GitHub workflow 也在最外层设置同一开关。这样即使 profile 为隔离权限而过滤 CI，或者父进程显式请求开启，typed sender 仍统一 fail closed。
正向路径是 launcher 构造环境 → child CLI/runtime/tool shell 继承固定 opt-out → TypeScript sender 接受 enable/status 请求但 sending=false → start/observe 不消费计数、不发 HTTP。普通用户 CLI 不经过这些 synthetic builders，原有 notice、explicit disable、consent-required 和 payload contract 都不变。负向路径通过父进程强制 enable、无 CI、tool-shell 重建与 disposable collector 验证，证明环境可用性或显式 enable 不能越过 synthetic boundary。
具体改动
完整 PR 修改 15 个文件、+183/-3。生产面中，_formal_install_environment 与 native_codex_profile_environment 固定安装/运行环境；native_codex_app_server_shell_policy_args 给 Agent shell 增加明确 set 项；canary _run_check 覆盖父环境；release qualification 的 host_environment 同时喂给 host 与 tool shell。CI 配置、pytest conftest、英文/中文 usage 文档、测试规范和 self-repair pattern 同步表达同一 obligation。
关键代码讲解
_formal_install_environment/native_codex_profile_environment：现有 allowlist 会主动丢弃多数父环境，因此不能依赖CI恰好被继承；在 owner 内固定0能覆盖安装、doctor、CLI 与 runtime。native_codex_app_server_shell_policy_args：include-only/exclude 之后新增shell_environment_policy.set.LOOPX_USAGE_PING="0"，防止 Agent 工具 shell 二次重建环境时恢复采集。_run_check与host_environment：分别覆盖本地/CI smoke 子进程与 release qualification，保留其他环境和凭据隔离语义。tests/conftest.py：pytest import 前固定 opt-out；真正测试 telemetry transport 的 case 会显式清除它并只对本地 collector 开启，因此关键正向 sender 行为仍被执行。- 新增的 profile telemetry test 走真实 CLI 和 TypeScript sender，断言 child enable 仍被阻断、start/observe 不改状态且 collector 零请求；这比只检查环境字典更有说服力。
对主干的风险
[P1] 新增 tool-shell 参数后，现有 benchmark/tests/test_native_codex_profile.py:105 仍精确断言旧的八项 tuple，并在 exclude=[...] 后结束。当前实现返回额外的 -c 与 shell_environment_policy.set.LOOPX_USAGE_PING="0"，因此 exact head 的完整文件稳定失败 1 项；immutable base 用同一命令 12/12 通过。这不是无关 flaky，也不是远端基线红灯，而是本 PR 改动公共 benchmark helper 后遗漏既有 contract consumer。
最小修复很小：更新该精确 tuple，使它继续同时约束 inherit、default excludes、include-only、exclude 和新 set 项；然后在 rebase 后重跑整个 benchmark/tests/test_native_codex_profile.py。不要删掉精确断言来换绿，它仍是 credential/environment fail-closed 的有价值边界。
其他验证结果正向：49 个相关 Python 测试、24 个 TypeScript usage/collector 测试、ruff、compile、control-plane typecheck 全通过；risk-based premerge 的 5 项 direct、10 项 catalog、8 项 risk-profile 和 1 项 public-boundary 检查都通过，只有 benchmark-sensitive 的人工 hold。远端 Frontstage/Release/chat-bundle 的 workspace_ref: "current" 失败来自 immutable base，并已在当前 main 的独立提交修复；聚合 check 的失败/跳过是独立 rebase/merge-readiness hold，但不能抵消本 PR 自己的 benchmark test 失败。
语义与 CI 对齐
这次没有 substring denylist、domain-specific core wording 或把 machine obligation 写成 guidance：既有 LOOPX_USAGE_PING typed contract 被原样复用，synthetic scope 由具体 launcher 明确产生，普通用户路径不受影响。语义本身 aligned；不完整之处是 CI selection 没有覆盖到已存在的 native profile exact contract，导致新专项测试全绿却仍留下仓库内确定性失败。
我的整体评价
方向、收益和实现边界都值得保留：这是在现有 owner 上增加很小的显式 opt-out，不引入 schema、sender、scheduler 或新 capability；base/head 真实子进程对照也证明它确实消除了 synthetic reporting request。long-horizon 上能阻止不可逆的数据污染，普通用户体验保持不变，相关 future-facing pass 不需要再抽象。
但完整 PR 还不能 approve，因为一个直接覆盖被改 helper 的既有 focused suite 已经被当前 head 打红。请同步该 exact expectation、rebase 到当前 main 并恢复 required checks，再提交新的 exact head 复审；修复范围应只需测试契约同步，不需要改变已验证有效的 telemetry 隔离机制。
English verdict: REQUEST_CHANGES - exact head bda6b0acadf7cada195c4dc020e84123d175e585 has a validated, proportionate isolation fix: an identical parent-enabled real child sends one request on the immutable base and zero on the head, and 49 focused Python plus 24 TypeScript tests pass. However, benchmark/tests/test_native_codex_profile.py passes 12/12 on base and fails 1/12 on head because its exact fail-closed shell-policy tuple was not updated for the new LOOPX_USAGE_PING=0 pair. Update that existing contract, rebase, and rerun it; the current remote dashboard failures are separate baseline failures fixed on main.
bda6b0a to
fcc970b
Compare
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
动机
复审精确 head fcc970bc45160e94d685499c99a46f0a3b93afbd。旧版 native 合成 profile 重建最小环境时会丢掉 CI 和父进程的遥测开关；新 HOME 因而能生成随机 installation ID，把测试计为真实采用。相同脚本、相同父进程显式开启条件、同一本地一次性收集器的基线/新头对照分别观察到 1 次和 0 次请求；新头也没有写入计数或发送尝试。这是可独立交付的数据质量修复，不涉及历史样本推断。
改动思路
安装器、profile CLI/runtime、Codex Agent 工具 shell、release qualification、pytest、canary 子进程和两个 CI 工作流各自拥有合成进程的环境创建边界，因此在这些边界固定 LOOPX_USAGE_PING=0。真正决定能否发送、如何持久化状态以及向哪里发送的仍是现有 TypeScript usage owner；Python 没有复制一套策略。正向路径是合成 launcher 注入关闭开关，真实 child CLI 仍正常返回版本和 doctor 结果，而 typed sender 的 sending 为 false。反向路径把父环境设为 1、清掉 CI 并重建 Agent shell，仍不能绕过子进程的关闭开关。普通用户 CLI 不走这些 builder，既有启用和披露路径由正向传输测试继续覆盖。
具体改动
完整差异为 16 个文件、+185/-3。三处 Python 环境 builder 和 canary subprocess 给合成子进程明确 opt-out；工作流与 pytest 提前设置相同边界，英文/中文参考文档及测试规范说明其适用范围。新增测试既检查最小环境和 Agent shell 配置，也运行真实 CLI、typed sender 与本地收集器。上次审查指出的 P1 是新增 shell 参数后遗漏旧的精确 fail-closed tuple；本次保留原断言并补入这组参数，最新基线上的整份 benchmark profile 文件 12/12 通过。
关键代码讲解
_formal_install_environment在正式安装前构造隔离 HOME 和 installer 环境，显式设置关闭开关，避免 allowlist 丢掉父进程信号。native_codex_profile_environment覆盖安装后的 CLI 和 runtime；native_codex_app_server_shell_policy_args再覆盖 Agent tool shell 的二次环境重建。- canary
_run_check在真实 subprocess 调用处覆盖父进程的开启值；releasehost_environment对 host 和 tool shell 使用同一明确的合成边界。 benchmark/tests/test_native_codex_profile.py继续逐项约束 inherit、include-only、exclude 与新 set 参数，没有用宽松断言掩盖凭据隔离契约。
对主干的风险
最强反例不是“环境字典里有 0”，而是父进程请求开启后真实 child 仍向默认收集器发送；基线/新头相同输入的一次性本地收集器对照已把这个反例打掉。另一风险是 pytest 的全局 opt-out 把正向遥测测试假绿：相关测试显式清除该变量，真实传输和 Goal/Turn/quota 路径通过，且无生产收集器请求。完整 native profile/skill-version/telemetry 套件 20/20，最终 rebased 关键子集 18/18，Python 使用/发布/canary 41/41，TypeScript usage 36/36；mypy、ruff、类型检查、编译和 16 文件公开边界扫描通过。预合并 5 项 direct、10 项 catalog、8 项 risk-profile、1 项 boundary 均无失败；benchmark-sensitive 的人工 hold 由本精确头审查承担，未启动 benchmark job。
原草稿曾有一次 formal_installer_failed，缺少足够 stderr，无法归因；此次真实安装完整套件通过，但不能把偶发原因说成已修好。可选的全量 TypeScript 控制面运行在 406 项通过、主干更新后停止，已在最终基线重跑受影响的 36 项和类型检查。本次未查询或等待远端 CI，合并资格另由即时门禁判断。
语义与 CI 对齐
本差异复用 typed LOOPX_USAGE_PING 阻断语义，没有新增 substring 分类、协议名、权限、评分或普通用户默认行为。基线的新语义预合并检查也已在 10 项 catalog canary 中通过。生产入口局限于合成启动边界，frontend 与 Lark 不消费这些环境 builder，无伴随界面改动。
我的整体评价
APPROVE。 P1 精确断言回归已修复，完整 PR 的目标、运行边界、负向绕过和普通用户正向路径都得到实证支持。相比为多个 launcher 新增共享策略层，直接复用已有 typed 开关更容易审查和回滚；相关 future-facing 检查无需再抽象。剩余的不确定性是旧头那次无法归因的安装失败，已在 PR 中明示。精确差异的质量验证有效；本结论只针对上述精确 head，合并还须即时 readiness 为 ready。
English verdict: APPROVE - exact head fcc970bc45160e94d685499c99a46f0a3b93afbd fixes the prior P1 contract test and blocks synthetic profile reporting. The same local-collector fixture produced one request on current main and zero on this head; focused Python, TypeScript, real installer, boundary and premerge checks passed. The earlier unattributed installer failure and stopped optional broad TypeScript run remain disclosed.
fcc970b to
9554756
Compare
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
动机
复审精确 head 955475676c78d69d42990bae437ee84dc94109fb。旧版 native 合成 profile 重建最小环境时会丢掉 CI 和父进程的遥测开关；新 HOME 因而能生成随机 installation ID，把测试计为真实采用。相同脚本、相同父进程显式开启条件、同一本地一次性收集器的基线/新头对照分别观察到 1 次和 0 次请求；新头也没有写入计数或发送尝试。这是可独立交付的数据质量修复，不涉及历史样本推断。
改动思路
安装器、profile CLI/runtime、Codex Agent 工具 shell、release qualification、pytest、canary 子进程和两个 CI 工作流各自拥有合成进程的环境创建边界，因此在这些边界固定 LOOPX_USAGE_PING=0。真正决定能否发送、如何持久化状态以及向哪里发送的仍是现有 TypeScript usage owner；Python 没有复制一套策略。正向路径是合成 launcher 注入关闭开关，真实 child CLI 仍正常返回版本和 doctor 结果，而 typed sender 的 sending 为 false。反向路径把父环境设为 1、清掉 CI 并重建 Agent shell，仍不能绕过子进程的关闭开关。普通用户 CLI 不走这些 builder，既有启用和披露路径由正向传输测试继续覆盖。
具体改动
完整差异为 16 个文件、+185/-3。三处 Python 环境 builder 和 canary subprocess 给合成子进程明确 opt-out；工作流与 pytest 提前设置相同边界，英文/中文参考文档及测试规范说明其适用范围。新增测试既检查最小环境和 Agent shell 配置，也运行真实 CLI、typed sender 与本地收集器。上次审查指出的 P1 是新增 shell 参数后遗漏旧的精确 fail-closed tuple；本次保留原断言并补入这组参数，最新基线上的整份 benchmark profile 文件 12/12 通过。
关键代码讲解
_formal_install_environment在正式安装前构造隔离 HOME 和 installer 环境，显式设置关闭开关，避免 allowlist 丢掉父进程信号。native_codex_profile_environment覆盖安装后的 CLI 和 runtime；native_codex_app_server_shell_policy_args再覆盖 Agent tool shell 的二次环境重建。- canary
_run_check在真实 subprocess 调用处覆盖父进程的开启值；releasehost_environment对 host 和 tool shell 使用同一明确的合成边界。 benchmark/tests/test_native_codex_profile.py继续逐项约束 inherit、include-only、exclude 与新 set 参数，没有用宽松断言掩盖凭据隔离契约。
对主干的风险
最强反例不是“环境字典里有 0”，而是父进程请求开启后真实 child 仍向默认收集器发送；基线/新头相同输入的一次性本地收集器对照已把这个反例打掉。另一风险是 pytest 的全局 opt-out 把正向遥测测试假绿：相关测试显式清除该变量，真实传输和 Goal/Turn/quota 路径通过，且无生产收集器请求。完整 native profile/skill-version/telemetry 套件 20/20，最终 rebased 关键子集 18/18，Python 使用/发布/canary 41/41，TypeScript usage 36/36；mypy、ruff、类型检查、编译和 16 文件公开边界扫描通过。预合并 5 项 direct、10 项 catalog、8 项 risk-profile、1 项 boundary 均无失败；benchmark-sensitive 的人工 hold 由本精确头审查承担，未启动 benchmark job。
原草稿曾有一次 formal_installer_failed，缺少足够 stderr，无法归因；此次真实安装完整套件通过，但不能把偶发原因说成已修好。可选的全量 TypeScript 控制面运行在 406 项通过、主干更新后停止，已在最终基线重跑受影响的 36 项和类型检查。本次未查询或等待远端 CI，合并资格另由即时门禁判断。
语义与 CI 对齐
本差异复用 typed LOOPX_USAGE_PING 阻断语义，没有新增 substring 分类、协议名、权限、评分或普通用户默认行为。基线的新语义预合并检查也已在 10 项 catalog canary 中通过。生产入口局限于合成启动边界，frontend 与 Lark 不消费这些环境 builder，无伴随界面改动。
我的整体评价
APPROVE。 P1 精确断言回归已修复，完整 PR 的目标、运行边界、负向绕过和普通用户正向路径都得到实证支持。相比为多个 launcher 新增共享策略层，直接复用已有 typed 开关更容易审查和回滚；相关 future-facing 检查无需再抽象。剩余的不确定性是旧头那次无法归因的安装失败，已在 PR 中明示。精确差异的质量验证有效；本结论只针对上述精确 head，合并还须即时 readiness 为 ready。
English verdict: APPROVE - exact head 955475676c78d69d42990bae437ee84dc94109fb fixes the prior P1 contract test and blocks synthetic profile reporting. The same local-collector fixture produced one request on current main and zero on this head; focused Python, TypeScript, real installer, boundary and premerge checks passed. The earlier unattributed installer failure and stopped optional broad TypeScript run remain disclosed.
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
9554756 to
a1d85c8
Compare
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
动机
复审精确 head a1d85c8bf2db258752962888e481ad573213f631。旧版 native 合成 profile 重建最小环境时会丢掉 CI 和父进程的遥测开关；新 HOME 因而能生成随机 installation ID，把测试计为真实采用。相同脚本、相同父进程显式开启条件、同一本地一次性收集器的基线/新头对照分别观察到 1 次和 0 次请求；新头也没有写入计数或发送尝试。这是可独立交付的数据质量修复，不涉及历史样本推断。
改动思路
安装器、profile CLI/runtime、Codex Agent 工具 shell、release qualification、pytest、canary 子进程和两个 CI 工作流各自拥有合成进程的环境创建边界，因此在这些边界固定 LOOPX_USAGE_PING=0。真正决定能否发送、如何持久化状态以及向哪里发送的仍是现有 TypeScript usage owner；Python 没有复制一套策略。正向路径是合成 launcher 注入关闭开关，真实 child CLI 仍正常返回版本和 doctor 结果，而 typed sender 的 sending 为 false。反向路径把父环境设为 1、清掉 CI 并重建 Agent shell，仍不能绕过子进程的关闭开关。普通用户 CLI 不走这些 builder，既有启用和披露路径由正向传输测试继续覆盖。
具体改动
完整差异为 16 个文件、+185/-3。三处 Python 环境 builder 和 canary subprocess 给合成子进程明确 opt-out；工作流与 pytest 提前设置相同边界，英文/中文参考文档及测试规范说明其适用范围。新增测试既检查最小环境和 Agent shell 配置，也运行真实 CLI、typed sender 与本地收集器。上次审查指出的 P1 是新增 shell 参数后遗漏旧的精确 fail-closed tuple；本次保留原断言并补入这组参数，最新基线上的整份 benchmark profile 文件 12/12 通过。
关键代码讲解
_formal_install_environment在正式安装前构造隔离 HOME 和 installer 环境，显式设置关闭开关，避免 allowlist 丢掉父进程信号。native_codex_profile_environment覆盖安装后的 CLI 和 runtime；native_codex_app_server_shell_policy_args再覆盖 Agent tool shell 的二次环境重建。- canary
_run_check在真实 subprocess 调用处覆盖父进程的开启值；releasehost_environment对 host 和 tool shell 使用同一明确的合成边界。 benchmark/tests/test_native_codex_profile.py继续逐项约束 inherit、include-only、exclude 与新 set 参数，没有用宽松断言掩盖凭据隔离契约。
对主干的风险
最强反例不是“环境字典里有 0”，而是父进程请求开启后真实 child 仍向默认收集器发送；基线/新头相同输入的一次性本地收集器对照已把这个反例打掉。另一风险是 pytest 的全局 opt-out 把正向遥测测试假绿：相关测试显式清除该变量，真实传输和 Goal/Turn/quota 路径通过，且无生产收集器请求。完整 native profile/skill-version/telemetry 套件 20/20，最终 rebased 关键子集 18/18，Python 使用/发布/canary 41/41，TypeScript usage 36/36；mypy、ruff、类型检查、编译和 16 文件公开边界扫描通过。预合并 5 项 direct、10 项 catalog、8 项 risk-profile、1 项 boundary 均无失败；benchmark-sensitive 的人工 hold 由本精确头审查承担，未启动 benchmark job。 后续主干仅新增无关的前端改动；重放前后 PR 完整补丁的 SHA-256 均为 72d59d788db5a9aec085d5d8d146416b5fee388fdb75763f3ae43a5b564efef6，新头重新通过 18 项 native 和 36 项 typed usage 测试、类型检查、编译及公开边界扫描。
原草稿曾有一次 formal_installer_failed，缺少足够 stderr，无法归因；此次真实安装完整套件通过，但不能把偶发原因说成已修好。可选的全量 TypeScript 控制面运行在 406 项通过、主干更新后停止，已在最终基线重跑受影响的 36 项和类型检查。本次未查询或等待远端 CI，合并资格另由即时门禁判断。
语义与 CI 对齐
本差异复用 typed LOOPX_USAGE_PING 阻断语义，没有新增 substring 分类、协议名、权限、评分或普通用户默认行为。基线的新语义预合并检查也已在 10 项 catalog canary 中通过。生产入口局限于合成启动边界，frontend 与 Lark 不消费这些环境 builder，无伴随界面改动。
我的整体评价
APPROVE。 P1 精确断言回归已修复，完整 PR 的目标、运行边界、负向绕过和普通用户正向路径都得到实证支持。相比为多个 launcher 新增共享策略层，直接复用已有 typed 开关更容易审查和回滚；相关 future-facing 检查无需再抽象。剩余的不确定性是旧头那次无法归因的安装失败，已在 PR 中明示。精确差异的质量验证有效；本结论只针对上述精确 head，合并还须即时 readiness 为 ready。
English verdict: APPROVE - exact head a1d85c8bf2db258752962888e481ad573213f631 fixes the prior P1 contract test and blocks synthetic profile reporting. The same local-collector fixture produced one request on current main and zero on this head; focused Python, TypeScript, real installer, boundary and premerge checks passed. The earlier unattributed installer failure and stopped optional broad TypeScript run remain disclosed.
…e app-server environment loopx-project#5272 makes every synthetic native Codex profile set LOOPX_USAGE_PING=0 so a rebuilt environment cannot become an adoption sample. The widesearch app-server environment test pins the exact variable set and did not include that opt-out, so it failed on main after loopx-project#5272. The opt-out is non-secret and required by that contract; the test still rejects provider credentials and unrelated private variables. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: song <22676124+songoow@users.noreply.github.com>
2 participants
Problem and result
Minimal CI and native benchmark profile environments can discard
CIand inherited telemetry opt-outs. With a fresh synthetic HOME, the ordinary usage sender can then create a random installation ID and report a test run as adoption. This PR forces the existingLOOPX_USAGE_PING=0opt-out at synthetic process boundaries; ordinary user collection and the typed usage policy remain unchanged. It does not reclassify historical samples.The same parent-enabled, fresh-profile child CLI was run against a disposable local collector on current
mainand this PR: the baseline made one HTTP request and recorded an attempt; the repaired head made zero requests and recorded neither counters nor an attempt.Change
The Python launchers only construct child environments. TypeScript remains the sole usage-policy and sender owner. There is no frontend or Lark entry-point change because these launchers do not serve either UI.
Validation and residual risk
ready=truebefore merge. Exact-diff change-quality validation is valid.An earlier installer invocation on the original head failed with
formal_installer_failedwithout enough diagnostics to attribute it; the complete installed-profile suite passed on the rebased source. An optional whole control-plane test run was stopped after 406 passing cases whenmainadvanced; the affected typed usage cases and typecheck were rerun on the final base. Neither observation is represented as a passing full-suite result.