youtube videos/comments list are API-key-only, don't honor --account (OAuth)

[BRO3886]

The --mine reads (activities, playlists, channels) authenticate via OAuth through getYouTubeServiceForAccount when --account is passed. But videos list and comments list only call getYouTubeServiceWithAPIKey, so --account doesn't work for them:

$ gog yt videos list --id <id> --account me@gmail.com
YouTube API key required: set config youtube_api_key KEY or GOG_YOUTUBE_API_KEY

Why it matters: YouTubeVideosListCmd.Run already requests []string{"snippet", "contentDetails", "statistics"}, so view/like/comment counts are right there — but a user authenticated via --account with no API key configured can't retrieve them at all.

Question: is the API-key-only path intentional for public catalog reads, or should videos/comments accept --account too, the way the --mine commands already do?

if flags.Account != "" {
    svc, err = getYouTubeServiceForAccount(ctx, flags.Account)
} else {
    svc, err = getYouTubeServiceWithAPIKey(ctx)
}

Happy to send a PR adding that branch to YouTubeVideosListCmd.Run and YouTubeCommentsListCmd.Run. (Related: I'm adding --account support to a new search command in #650, currently open — this would keep public reads consistent with that.)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed May 30, 2026, 2:43 PM ET / 18:43 UTC.

Summary
This should stay open: current main still ignores --account for the existing YouTube videos and comments list commands, so users without a YouTube API key still hit the API-key-required path even when they have OAuth credentials.

Reproducibility: yes. at source level rather than through a live Google run. Both affected Run methods unconditionally choose the API-key service, so the reported --account path cannot work on current main.

Next step
This is a narrow current-main source repair in two YouTube list commands plus tests; the related search PR is open but does not own videos/comments behavior.

Review details

Best possible solution:

Honor an explicitly supplied account for videos/comments through the existing OAuth service helper, keep the no-account API-key fallback unchanged, and add focused tests plus live Google proof for both command paths.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level rather than through a live Google run. Both affected Run methods unconditionally choose the API-key service, so the reported --account path cannot work on current main.

Is this the best way to solve the issue?

Yes. The narrow maintainable fix is to branch on flags.Account in those two commands, preserve the existing API-key fallback when no account is supplied, and cover both selectors with unit tests.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A follow-up PR should clarify docs if videos/comments start accepting explicit --account, because README currently describes API-key reads and OAuth mainly for --mine reads.
• Live Google proof will still be needed before merge because the changed behavior depends on real YouTube OAuth/API-key credentials.

Codex review notes: model gpt-5.5, reasoning high; reviewed against e4941e776504.

Label changes

Label changes:

• add P2: This is a valid, bounded CLI auth-path bug in an existing command group, but it has limited blast radius and a clear workaround via API key.
• add impact:auth-provider: The issue is specifically about account/OAuth selection being ignored in favor of API-key authentication for YouTube reads.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: This is a valid, bounded CLI auth-path bug in an existing command group, but it has limited blast radius and a clear workaround via API key.
• impact:auth-provider: The issue is specifically about account/OAuth selection being ignored in favor of API-key authentication for YouTube reads.

Evidence reviewed

Acceptance criteria:

• make fmt
• go test ./internal/cmd

What I checked:

• Current videos list path is API-key-only: YouTubeVideosListCmd.Run validates the request, then unconditionally calls getYouTubeServiceWithAPIKey(ctx) before building the Videos.List request; flags.Account is not consulted in this command. (internal/cmd/youtube.go:136, e4941e776504)
• Current comments list path is API-key-only: YouTubeCommentsListCmd.Run likewise unconditionally calls getYouTubeServiceWithAPIKey(ctx), so a supplied account cannot select OAuth for comment-thread reads. (internal/cmd/youtube.go:292, e4941e776504)
• Adjacent YouTube commands already branch to OAuth: activities, playlists, and channels use requireAccount(flags) plus getYouTubeServiceForAccount for their authenticated --mine paths, which shows the existing local pattern for YouTube OAuth service selection. (internal/cmd/youtube.go:48, e4941e776504)
• Generated command docs expose the global account flag: Generated docs for both youtube videos list and youtube comments list include the global --account flag, but the current command implementations do not use it. (docs/commands/gog-youtube-videos-list.md:22, e4941e776504)
• History points to the original YouTube command surface: Commit 05dd666075834cf62d03f2434ce630923ef0a13d added the YouTube command group, generated docs, service helpers, and tests; later YouTube auth maintenance touched the same area in e8c17cbc37be3c7ca1c891800add640cf9afc0ef. (internal/cmd/youtube.go, 05dd66607583)
• Related work does not supersede this issue: The provided GitHub context shows Add YouTube search command #650 is still open and adds a new YouTube search command; it does not fix the existing videos/comments list auth path.

Likely related people:

• Kuldip Satpute: Commit 05dd666075834cf62d03f2434ce630923ef0a13d added the YouTube command group, including videos/comments list, service helpers, generated command docs, and tests. (role: introduced behavior; confidence: high; commits: 05dd66607583; files: internal/cmd/youtube.go, internal/cmd/youtube_services.go, internal/cmd/youtube_test.go)
• Peter Steinberger: Recent commits touched YouTube auth behavior and release integration, including the API-key retry transport fix and release commit containing the current YouTube files. (role: recent area contributor; confidence: medium; commits: e8c17cbc37be, b25a3c029b37; files: internal/googleapi/youtube.go, internal/cmd/youtube.go, internal/cmd/youtube_services.go)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.