### 🔎 Existing issue check - [x] I have searched the existing issues. ### 🎯 Affected area Native workflow runtime (`domains/comet-native`) ### 📦 Comet version 0.5.0 ### 💥 Current behavior 0.5.0 的 SDK Runtime 在 Verifier `record-outcome` 提交 `final-result` 时,会在**提交命令所在的进程**里重算检查输入指纹,再与检查记录的 `inputAfter` 比对。指纹会绑定 `NATIVE_CHECK_BOUND_ENV`(包含 `PATH`、`TEMP`、`HTTP_PROXY`、`HTTPS_PROXY`、`NO_PROXY` 等)在**当前进程**里的值。 因此,只要「跑检查的 shell」和「Verifier 提交的 shell」环境变量不同,即使代码完全没变,提交也会被拒: ``` OUTCOME_REJECTED: Native 检查输入已变化;保留 Verify,由当前 Verifier 请求原检查并提交 refreshChecks: true… ``` 按提示刷新检查后,提交仍然被拒,形成死循环。我们连续被拒 3 次,直到让 Verifier 在相同的环境变量下提交才被接受。0.4.5 没有这一步提交时的复核,所以之前没遇到过。 相关代码:`native-sdk-checks.js` 的 `validatedCheckResults()`,`native-portable-checks.js` 的 `nativeCheckInputFingerprint()`。 ### ✅ Expected behavior 同一个候选、同一份工作区,Verifier 只是从另一个 shell 或会话提交结论,不应被判定为「检查输入已变化」。确实需要拒绝时,应说明是哪一部分不一致,且不应在刷新检查后反复要求 `refreshChecks`。 ### 🔁 Steps to reproduce ```bash # shell A:去掉代理后执行检查 unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy comet native next <change> --json # shell B:保留代理,领取 verify.verifier 并提交 final-result comet runtime dispatch --application native --request outcome.json --project-root <root> --json # → OUTCOME_REJECTED: Native 检查输入已变化 # shell B 同样 unset 代理后再提交 → succeeded ``` ### 🖥️ Environment - OS: Windows 11 Pro 10.0.26100 - Shell: Git Bash - Node: v24.16.0 - Package manager: pnpm - Install scope: global - Skill language: zh - Target AI platform(s): Claude Code(Builder 与 Verifier 分别在不同的 Agent 会话中执行) - Runtime format: `sdk` ### 💡 建议修复 1. 提交结论时只复核与候选内容相关的部分(Git 快照、候选 ID)。工具环境部分只用于判断是否复用旧检查,不作为拒绝结论的理由。 2. 至少把 `HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY` 移出绑定清单。它们几乎不影响 `tsc`、单元测试这类检查的结果,却常常随会话不同而不同。 3. 指纹不一致时,在报错里给出差异项的键名(不输出值),并在刷新检查后差异依旧时,直接提示「提交环境与检查环境不同」,避免死循环。 ### 🧩 Additional context 相关:#455(同类的指纹漂移,诱因是 `.pytest_cache`)
Activity
guijianhongyan commentedon Oct 24, 2026
俺也一样。
@benym 大佬快修修
AntonyLang commentedon Oct 24, 2026
想参与这个问题的修复,先确认一下范围。
静态看了当前 master:validatedCheckResults() 会在提交结果的进程里重新计算 nativeCheckInputFingerprint(),其中包含当前进程的代理、PATH、TEMP 等环境变量。目前还没有实际复现或运行测试。
我倾向于区分“原检查的执行上下文”和“Verifier 提交时的环境”:提交时仍校验候选、工作区和检查计划是否变化;检查的环境绑定保留,但不把提交者换了 shell 当作原检查输入变化,不直接删除环境校验。验证会重点覆盖跨 shell 提交,以及代码或实际检查输入变化后不能沿用旧结果。
看到这个 issue 还在 needs-triage,先不开始实现。@benym 这个范围是否适合我接手?如果你已经在处理,也请告诉我,避免重复。
benym commentedon Oct 24, 2026
@AntonyLang 050新增的问题比较多,我先快速修复这些问题了,051版本发布后后续可以观察仓库中的新issue进行认领