When your GitHub token is rate-limited, socket scan github currently tells you it succeeded. It exits 0 and prints:

✔ N GitHub repos detected
✔ 0 with supported Manifest files

Nothing was uploaded. Every repo failed, and the run reported green. On a laptop that is confusing; in CI it is worse, because a pipeline step that exits 0 is a pipeline step nobody looks at. Teams can go a long time believing their repos are being scanned when no scan has happened at all.

After this change, a rate-limited, unauthorized, or abuse-throttled run stops at the first blocking error, prints what hit and — when GitHub tells us — when it resets, and exits non-zero. Genuinely empty repos with no manifests still succeed, exactly as before.

Refs ASK-167.

The GitHub-API scanning path read every GitHub REST response body and JSON-parsed it without ever checking the HTTP status. When a token is rate-limited, GitHub answers with one of three shapes:

None of those parse into the JSON the code expected, so the old code read them as "repo has no default branch / no manifests". The per-repo error was then swallowed by the scan loop, and the run finished with the success lines above.

New utils/github-errors.mts holds two pieces:

• classifyGitHubResponse detects rate-limit, abuse-detection and auth responses and returns a clear, actionable CResult error. It returns nothing for anything else, so the caller keeps its own handling of 404s, empty repos and the rest.
• githubApiRequest is a bounded-retry wrapper around apiFetch. It waits once and retries when the reset window is short (Retry-After or x-ratelimit-reset within 30 seconds), surfaces long hourly resets immediately rather than blocking a CLI run on them, retries 5xx and network failures with capped exponential backoff, and never retries an auth failure.

Wired in at the call sites:

• The repo-details, tree, commit and contents calls all go through githubApiRequest. The raw manifest-download host is checked too, so a bulk run that trips the limit mid-download fails loudly instead of counting the file as skipped.
• The per-repo loop is extracted into runGithubScanLoop, which stops at the first blocking error (rate limit / auth / abuse) and returns ok: false, giving a non-zero exit. A run where every repo failed is also no longer reported as success.

The success line now reads N GitHub repos processed rather than N GitHub repos detected, since "detected" was part of what made the old output read as a completed scan.

src/utils/github-errors.test.mts and src/commands/scan/create-scan-from-github.test.mts. Fake fetch and scanRepoFn are injected as plain functions rather than mocked at the module level, so the tests exercise the real decision logic.

They cover detection of 403 + remaining: 0, 429, secondary-limit and 401; Retry-After and reset parsing; the cheap-retry-then-succeed path; 5xx backoff; the loop stopping on a blocking error and returning a non-zero exit; and an empty repo still succeeding.

Ran:

Test Files  2 passed (2)
     Tests  25 passed (25)

tsgo, eslint, and biome are clean on the changed files.

main already carries an equivalent Octokit-based fix, so no companion PR is needed there.

This ports the same behavior to the shipping v1.x line, adapted to its raw-apiFetch architecture.