feat(miner): add offline GitHub-token and coding-agent-credential presence checks to doctor (#5170) - #5341
Conversation
…sence checks to doctor (JSONbored#5170) runDoctorChecks() made zero network calls but never verified GITHUB_TOKEN was set, nor that the credential the configured MINER_CODING_AGENT_PROVIDER actually needs was present -- an operator could pass doctor cleanly and then have their first real attempt fail mid-run on a missing credential. Adds two new offline checks: github-token-present (string presence/length only) and coding-agent-credential-present, keyed off the same resolveFirstConfiguredCodingAgentDriverName resolution status.js's driver section already uses. noop/agent-sdk are locally-authenticated with no separate credential this repo tracks, so they (and an unconfigured provider) report ok: true advisory; claude-cli/codex-cli reuse the exact credential conditions checkClaudeCliPresent/checkCodexCliPresent already probe (CLAUDE_CODE_OAUTH_TOKEN / the codex auth.json path, exported as resolveCodexAuthPath) rather than re-deriving them, and fail doctor when missing. Never prints a credential's actual value -- only presence, env-var names, and file paths.
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5341 +/- ##
==========================================
+ Coverage 85.99% 94.41% +8.42%
==========================================
Files 550 550
Lines 44116 44130 +14
Branches 14631 14631
==========================================
+ Hits 37936 41665 +3729
+ Misses 4894 1790 -3104
+ Partials 1286 675 -611
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
Caution 🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥 🛑 Gittensory review result - reject/close recommendedReview updated: 2026-07-12 14:15:50 UTC
🛑 Suggested Action - Reject/Close
Review summary Nits — 1 non-blocking
Why this is blocked
Review context
Contributor next steps
Signal definitions
[BETA] Chat with GittensoryAsk Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.
|
|
Gittensory is closing this pull request on the maintainer's behalf (Possible leaked secret in the diff (generic_secret_assignment)). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed. |
) PR #5346 (a resubmission of #5341) was auto-closed over two inert test-fixture strings that matched the generic_secret_assignment keyword-plus-quoted-value SHAPE but weren't real credentials -- the same heuristic has now caused at least eight prior false-positive incidents (#2613, #3178, #3673, #3866, #4587, #4733, plus several fixture-rewording commits), each patched by narrowing an allowlist rather than fixing the underlying design. REES's own copy of this rule already rates it "medium confidence" ("catches real keys but also the occasional long opaque non-secret"), and content-lane/security-scan.ts's own header states the design principle this violated: a gate that auto-closes with no human queue may only hard-close on a signal unambiguous enough that a false positive is essentially impossible. Split generic_secret_assignment out of HARD_SECRET_KINDS into a new ADVISORY_ONLY_SECRET_KINDS: it still surfaces (a warning-severity possible_secret_assignment finding / a "manual" content-lane verdict), but never auto-blocks or auto-closes on its own. Concrete credential formats (github_token, aws_access_key, private_key_block, ...) are unaffected and remain unconditional hard blockers. Also add a structural placeholder heuristic (looksLikeDescriptive PlaceholderPhrase, mirrored in REES): a value with 5+ lowercase-only hyphen/underscore segments containing an English function word reads as written prose describing the value, not a credential or a chosen passphrase -- this independently resolves both PR #5346 literals without weakening detection of a genuine human-chosen passphrase like "correct-horse-battery-secret" (no function words, by design).
…ry references src/sentry.ts's resolveReesSentryRelease() defaulted every REES release id to "gittensory-rees@<sha>" when SENTRY_RELEASE wasn't set -- same live bug class as JSONbored#6876/JSONbored#6881, this time in REES's own separate Railway deploy rather than the main app. Fixed the default and every test/doc reference describing that exact format (README.md's Sentry setup guide, sentry-upload/sentry-release-validation/sentry-degradation tests). The remaining ~70 occurrences across analysis-context, analyzer-registry, analyzer-circuit-breaker, external-fetch, render-contract, request-guardrails, and scheduler tests were all an arbitrary "JSONbored/gittensory" placeholder repoFullName fixture value -- any string works equally to test that logic, so this is a consistency-only cleanup, not a bug fix. analyzer-circuit-breaker.test.ts's casing REGRESSION test ("jsonbored/gittensory" vs "JSONbored/Gittensory") preserves the exact same casing-variation relationship with "jsonbored/loopover" / "JSONbored/Loopover". Left untouched: GITTENSORY-15 (a Sentry ticket id, permanent regardless of the project rename) and two historical PR/issue citations in secret-scan.ts/.test.ts ("gittensory PR JSONbored#5346/JSONbored#5341", "metagraphed/gittensory#4524") -- PR/issue numbers are stable identifiers independent of a repo rename, and the second one's cross-repo shape wasn't clear enough to edit with confidence. All 1335 review-enrichment tests pass.
Summary
gittensory-miner doctor's checks make zero network calls (a documented invariant) but never verifiedGITHUB_TOKENwas set, nor that the credential required by whicheverMINER_CODING_AGENT_PROVIDERis configured was present. An operator could passdoctorcleanly and then have their first real attempt fail mid-run purely on a missing credential.runDoctorChecks():github-token-present-- string presence/length check only (no API call) onGITHUB_TOKEN.coding-agent-credential-present-- keyed offresolveFirstConfiguredCodingAgentDriverName(the same resolutionstatus.js'sdriversection, Surface the resolved coding-agent-driver provider and CLI presence ingittensory-miner status --json#5164, already uses):claude-cliconfigured -- checksCLAUDE_CODE_OAUTH_TOKENis set and non-empty (the same conditioncheckClaudeCliPresentalready probes).codex-cliconfigured -- checks the codexauth.jsonpath (exportedresolveCodexAuthPathfromlaptop-init.js, reused rather than re-derived) is readable.noop/agent-sdkconfigured, or no provider configured --ok: trueadvisory, since these are locally-authenticated with no separate credential this repo tracks (driver-factory.ts's own comment: "All are locally-authenticated (no API-key env requirement)"). I did not invent a fake API-key check foragent-sdksince the actual architecture has none today -- the issue's generic phrasing doesn't quite match this repo's current driver set, so this reports the honest state instead.Test plan
npx vitest run test/unit/miner-status.test.ts-- 33/34 passing (one pre-existing, unrelated Windows-onlypath.joinseparator failure, confirmed viagit stashto exist identically without this PR). Newdescribe("doctor credential-presence checks (#5170)", ...)block covers:GITHUB_TOKENpresent/absent (regression guard), unconfigured-provider advisory,noop/agent-sdkadvisory with no secret in the message,claude-clitoken present/missing,codex-cliauth.json present/missing, a zero-network-call assertion, and an invariant that doctor's--jsonoutput never contains an actual credential value.GITHUB_TOKENso they remain genuinely healthy with the two new checks added.npm run typecheck-- clean.npm run build:miner-- clean (node --checkon every shipped miner lib file passes).npm run docs:drift-check-- clean.packages/gittensory-miner/**currently sits outside vitest'scoverage.includeglob (per the issue's own Codecov-visibility note), socodecov/patchcannot measure this change yet -- treating the tests above as the enforced house standard regardless, per the issue's instructions.npm run test:coveragelocally (shared/resource-contended machine); relying on the targeted test run above plusnpm run typecheck/build:miner.Fixes #5170.