Verified live — 4 wrong closes
2026-07-09 JSONbored/metagraphed#4600 Patch-less file(s) could not be fully scanned for secrets (1)
2026-07-18 JSONbored/loopover#7155 Patch-less file(s) could not be fully scanned for secrets (1)
2026-07-20 JSONbored/loopover#7431 Patch-less file(s) could not be fully scanned for secrets (1)
2026-07-24 JSONbored/loopover#8376 …; Patch-less file(s) could not be fully scanned for secrets
Each of these is a legitimate PR one-shot-closed because ORB failed to fetch the file — absence of evidence treated as presence of a violation.
Why it is so hard to escape
src/queue/patchless-secret-scan.ts ~158-165 emits code secret_leak, severity critical, when a file is merely unscannable. A file is marked incomplete on any of: getFileContent returns null (~213/226/235), content > 4 MB (~214/227/236), any thrown error (~244-245), or the PR exceeding the 100-fetch budget — which marks every eligible patch-less file (~195-197).
From there it is uniquely unstoppable:
resolveConfiguredGateMode (src/rules/advisory.ts ~1065) returns "block" for secret_leak unconditionally — no maintainer opt-in exists.- Gate →
failure → willClose (src/settings/agent-actions.ts ~1074) → one-shot close.
secret_leak is in CONCRETE_EVIDENCE_BLOCKER_CODES (~214) → closeConcreteEvidence: true → exempt from downgradeCloseToHold, so the close-precision breaker can never catch it.- Executor:
closeRequiresCiState: "not_required", closeRequiresMergeableState: false, closeKind: "heuristic" → zero live re-verification (src/services/agent-action-executor.ts ~416-439).
Trigger in practice: a PR adding a binary or large file where the Contents API 404s, 5xx-es, or rate-limits; a file over 4 MB; or ~51+ modified patch-less files. The file's own header (~8-14) documents that this already fired in production on every regenerated-artifact PR — the previous fix raised the fetch cap rather than fixing the disposition.
Fix
Emit a distinct code (secret_scan_incomplete), keep it critical, but route it through isEvaluationBlocker (advisory.ts ~1006-1019) → neutral / hold, exactly like pre_merge_check_unresolved. Never place it in CONCRETE_EVIDENCE_BLOCKER_CODES. A real, found credential keeps the current always-block behavior.
Also worth reopening the four PRs above.
Acceptance
- A PR whose files cannot be fetched is held for a human, never closed.
- A genuine committed credential still hard-blocks.
Verified live — 4 wrong closes
Each of these is a legitimate PR one-shot-closed because ORB failed to fetch the file — absence of evidence treated as presence of a violation.
Why it is so hard to escape
src/queue/patchless-secret-scan.ts~158-165 emits codesecret_leak, severitycritical, when a file is merely unscannable. A file is marked incomplete on any of:getFileContentreturns null (~213/226/235), content > 4 MB (~214/227/236), any thrown error (~244-245), or the PR exceeding the 100-fetch budget — which marks every eligible patch-less file (~195-197).From there it is uniquely unstoppable:
resolveConfiguredGateMode(src/rules/advisory.ts~1065) returns"block"forsecret_leakunconditionally — no maintainer opt-in exists.failure→willClose(src/settings/agent-actions.ts~1074) → one-shot close.secret_leakis inCONCRETE_EVIDENCE_BLOCKER_CODES(~214) →closeConcreteEvidence: true→ exempt fromdowngradeCloseToHold, so the close-precision breaker can never catch it.closeRequiresCiState: "not_required",closeRequiresMergeableState: false,closeKind: "heuristic"→ zero live re-verification (src/services/agent-action-executor.ts~416-439).Trigger in practice: a PR adding a binary or large file where the Contents API 404s, 5xx-es, or rate-limits; a file over 4 MB; or ~51+ modified patch-less files. The file's own header (~8-14) documents that this already fired in production on every regenerated-artifact PR — the previous fix raised the fetch cap rather than fixing the disposition.
Fix
Emit a distinct code (
secret_scan_incomplete), keep itcritical, but route it throughisEvaluationBlocker(advisory.ts~1006-1019) → neutral / hold, exactly likepre_merge_check_unresolved. Never place it inCONCRETE_EVIDENCE_BLOCKER_CODES. A real, found credential keeps the current always-block behavior.Also worth reopening the four PRs above.
Acceptance