Skip to content

Router -DryRun 'key presence' path shells out to real 'gh auth token' (pre-Step-37 hermeticity gap) #51

Description

@aberson

Discovered during Step 37 (#46) review; pre-existing, out of that step's scope.

runtime/skill-router.ps1's -DryRun "Key presence" diagnostic calls Get-CopilotToken, whose source precedence falls through to a real & gh auth token subprocess when no COPILOT_GITHUB_TOKEN/GH_TOKEN/GITHUB_TOKEN env var is set. Any test (or operator dry-run) that exercises the router without stubbing a Copilot token therefore resolves the operator's real GitHub credential from the local gh keyring as a side effect.

Empirically: a PATH-shimmed gh logged 15 auth token invocations across the router test suite — all attributable to pre-existing (Step-34-era) dry-run diagnostic tests (test_router_scenarios.py pre-existing tests, test_shim_parity.py, test_spend_ledger_guard.py). Step 37's own transport tests make zero such calls (fixed there). No real network egress occurs (base URLs are hermetic in tests), but the real token is read + held in memory.

Fix: either (a) have the dry-run "key presence" check report presence WITHOUT invoking gh auth token (check env/keyring presence without materializing the value), or (b) set a fake GH_TOKEN (not unset) in the affected pre-existing tests / a shared conftest so Get-CopilotToken never reaches the gh auth token fallback.

Same defect class Step 37 closed for its own tests; tracked here for a future step.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions