GitHub crawl recovery

Date: 2026-08-04

Incident

The IONOS production environment had MCP_VERIFY_GITHUB_TOKEN defined but empty. GitHub topic discovery could make a limited number of anonymous requests, while the configured GitHub code-search source could not authenticate and was skipped by the best-effort registry ingest loop.

Remediation

• Installed the existing sentinelsignal GitHub CLI credential in /etc/sentinel-signal/prod.env on the IONOS host. The token value was not printed, logged, or committed.
• Kept the token outside the repository and restricted the production environment file to root access.
• Added a crawler guard that rejects any GitHub repository explicitly marked private or internal before normalization or persistence.
• Added regression fixtures proving topic search and code search discard private repositories while retaining public repositories.
• Bounded third-party directory titles before persistence so an overlong downstream Glama display name cannot fail the registry job after GitHub discovery succeeds.
• Extended the registry-sync worker lease to one hour while retaining the five-minute default for ordinary jobs, preventing long multi-source crawls from being reaped and run concurrently.

Production validation

After deployment, validate from a Verify worker container:

1. MCP_VERIFY_GITHUB_TOKEN is non-empty without printing its value.
2. GET /rate_limit reports authenticated core and search limits.
3. A one-page GitHub topic search returns public repositories.
4. A one-page GitHub code search returns public repositories.
5. The next registry_sync completes and GitHub-sourced inventory timestamps advance.

Credential maintenance

If the GitHub credential is revoked or rotated, replace only MCP_VERIFY_GITHUB_TOKEN in /etc/sentinel-signal/prod.env, recreate the Verify workers, and repeat the production validation above. Do not place the token in Compose, documentation, shell history, or source control.