feat(cli): log token scope at start of fullsend run

[ralphbean]

Summary

• At the start of every fullsend run, introspect GH_TOKEN via GET /installation/repositories and log which repos the token is scoped to.
• Non-fatal: if the token isn't an installation token or the call fails, a warning is logged and the run continues.
• Would have helped discover the cross-org token issue in Triage agent should not label ready-to-code when it identifies an existing PR that addresses the issue #1321 immediately rather than after the fact.

Refs: #1321

Test plan

• TestFetchTokenScope_ReturnsRepoNames — happy path
• TestFetchTokenScope_EmptyToken — skips gracefully
• TestFetchTokenScope_APIError — returns error
• TestFetchTokenScope_NonInstallationToken — 403 treated as error
• Full cli test suite passes

🤖 Generated with Claude Code

[github-actions]

Site preview

Preview: https://885d563a-site.fullsend-ai.workers.dev

Commit: 07cc6ae96465e65f78d07bad6f4f95351a3f021f

[fullsend-ai-review]

Review

Reason: stale-head

The review agent reviewed commit adaa55cef0d13fe74b2e26407eac4b54f674c468 but the PR HEAD is now 3c1080db1ae0e6d3d17893e090ef6a81537207d4. This review was discarded to avoid approving unreviewed code.

[waynesun09]

Review Squad (10 agents) — 1 HIGH, 4 MEDIUM findings

Useful diagnostic feature with solid test coverage. The HIGH finding (pagination truncation at 100 repos) is the most actionable — large orgs will get silently incomplete output, defeating the debugging purpose. The hardcoded base URL, missing context.Context, empty repo list handling, and package-level client are standard code quality improvements.

[waynesun09]

HIGH — Installations with >100 repos silently truncated

per_page=100 with no pagination and no total_count check. Large orgs with >100 repos in the installation scope will silently show only the first 100, with no indication the list is incomplete. This is the exact scenario (large multi-org deployments) this debugging feature is meant to help with.

Suggest parsing total_count from the response and appending a suffix when truncated:

if result.TotalCount > len(repos) {
    repos = append(repos, fmt.Sprintf("... and %d more (%d total)",
        result.TotalCount-len(repos), result.TotalCount))
}

This avoids pagination complexity while ensuring operators know the list is incomplete.

9/10 review agents flagged this (near-unanimous)

[ralphbean]

Fixed in 07cc6ae. Parsing total_count and appending a suffix when truncated, as you suggested.

[waynesun09]

MEDIUM — Hardcoded api.github.com breaks GHES

GitHub Actions sets GITHUB_API_URL for GHES runners. If GHES support is ever added, this call will silently hit the wrong API.

apiURL := os.Getenv("GITHUB_API_URL")
if apiURL == "" {
    apiURL = "https://api.github.com"
}
repos, err := fetchTokenScope(ghToken, apiURL)

5/10 review agents flagged this

[ralphbean]

I left this one as-is. No GHES support exists anywhere in the codebase — GITHUB_API_URL isn't referenced in any Go file. Adding it here alone wouldn't actually enable GHES support, and I'd rather not introduce a one-off pattern that diverges from every other API call. Do you see a nearer-term need for this?

[waynesun09]

MEDIUM — No context.Context parameter — request is uncancellable

Uses http.NewRequest instead of http.NewRequestWithContext. The 10s http.Client.Timeout is the only deadline mechanism — the request can't be cancelled if runAgent is interrupted (e.g., SIGTERM). The rest of the codebase uses context.Context throughout (e.g., forge/github.LiveClient.do()).

func fetchTokenScope(ctx context.Context, token, baseURL string) ([]string, error) {
    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel()
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    ...
}

4/10 review agents flagged this

[ralphbean]

Fixed in 07cc6ae. Using http.NewRequestWithContext with a 5s timeout context now.

[waynesun09]

MEDIUM — Empty repo list silently ignored

When fetchTokenScope returns a non-nil empty slice (installation token with 0 repos), the len(repos) > 0 guard silently skips it. An installation token scoped to zero repos is a significant misconfiguration that will cause downstream agent failures.

} else if len(repos) > 0 {
    printer.KeyValue("Token scoped to", strings.Join(repos, ", "))
} else {
    printer.StepWarn("Token is an installation token but has access to 0 repositories")
}

2/10 review agents flagged this

[ralphbean]

Fixed in 07cc6ae. Distinguishing nil (non-installation token) from empty slice (0 repos) now — the latter gets a warning.

[waynesun09]

MEDIUM — Package-level mutable HTTP client

tokenScopeClient is a package-level var, making the function harder to test in isolation and inconsistent with the rest of the codebase where HTTP clients are struct fields (forge/github.LiveClient.http, mint.Server.httpClient). Consider passing *http.Client as a parameter instead.

3/10 review agents flagged this

[ralphbean]

I left this one too. There's already a package-level httpClient at run.go:1820, so this is consistent with the file's existing pattern. The tests work fine against httptest servers as-is. Does it feel worth the churn to you for a single-use internal function?

[waynesun09]

Thanks for the thorough responses. The three fixes (truncation indicator, context.Context, empty repo warning) all look correct and well-tested. The two pushbacks are reasonable — agreed on both: no point adding a one-off GHES pattern, and the package-level client is consistent with the existing httpClient in the same file.