GitHub plugin silently discards extraRepos entries that are not owner/repo

[MPIsaac-Per]

Summary

The GitHub plugin's extraRepos setting silently discards any entry that is not exactly owner/repo. I set it to MPIV-AI/* expecting the org's repos to be tracked, and nothing happened: no error in the settings form, no warning in the log, no change in bb github repos. The setting stored my value and the plugin ignored it, which is indistinguishable from a setting that worked but found nothing.

I expected either the wildcard to be honored or, failing that, to be told it was not.

Versions and environment

• bb from source at ad79bbb5e, run with scripts/bb-dev-app current.
• Also reproduced on the packaged desktop app 0.39.0 (github@0.2.1).
• macOS 15.6 (Darwin 25.6.0), Node 24.19.0.
• gh 2.86.0, authenticated to github.com.

Steps to reproduce

bb plugin config github set extraRepos "SOME-ORG/*"
bb plugin reload github
bb github repos

Any string that fails /^[\w.-]+\/[\w.-]+$/ reproduces it. A bare typo does too:

bb plugin config github set extraRepos "get-bb/bb, nonsense"
bb github sync

What does not reproduce it: a well-formed owner/repo entry, which tracks correctly.

Expected vs actual

bb plugin config github confirms the value is stored:

extraRepos = "MPIV-AI/*"  (string)
  Extra repositories — Comma-separated "owner/repo" list to track in addition to repos discovered from BB projects.

Actual, bb github repos — only the repos discovered from BB project checkouts, with no mention of the setting:

mpiv-ai/mpiv-main	(proj_yfvfyfwqkt)
mpiv-ai/kept	(proj_vrmb7zhsvg)
mpiv-ai/rig	(proj_ppswj7vb9d)
mpiv-ai/receptn	(proj_m437zwj9hw)

Nothing appears in the server log for the discarded entry. Expected: a warning naming the entry and the shape the setting wants.

Evidence

The parse keeps only entries that pass isRepoName and drops the rest with no else branch:

• https://github.com/get-bb/bb/blob/ad79bbb5e/plugins/github/server.ts#L612-L616
• isRepoName is the filter: https://github.com/get-bb/bb/blob/ad79bbb5e/plugins/github/server.ts#L344-L346
• The setting's description does not say wildcards are unsupported: https://github.com/get-bb/bb/blob/ad79bbb5e/plugins/github/server.ts#L479-L485

* is not in [\w.-], so MPIV-AI/* fails the test and the loop body never runs for it.

What you ruled out

• Not a gh auth problem: valid entries in the same setting track fine, and gh repo list MPIV-AI returns 26 repos for this account.
• Not a sync failure: the sync reports success, having simply never been given the repo.
• Not a duplicate of GitHub plugin cannot target a GitHub Enterprise Server host #2313. That issue is about the plugin being pinned to github.com and unable to reach a GHE host; this is about the parse dropping input on the host it already talks to.
• Still present on main at ad79bbb5e.

Suggested priority and effort

Low effort. Hits anyone who guesses at the setting's syntax, and the failure is silent, so the time lost is spent wondering whether the plugin is broken. Workaround is to list every repo explicitly.

AGENT GENERATED

[SawyerHood]

Reproduction & root-cause report: https://get-bb.github.io/reports/issues/2540.html

• Verdict: REPRODUCED · root-cause confidence: high
• Root cause (short): The GitHub plugin accepts free-form extraRepos text, then a one-branch regular expression filter drops each invalid entry without a diagnostic.
• Linked PR review: Warn when an extraRepos entry cannot track a repository #2541 → REQUEST CHANGES — The patch repeats the same warning after each forced discovery, and the repository-list command still gives no direct diagnostic.; fix(github): report extraRepos entries that are not owner/repo #2545 → MERGE — The patch reports invalid entries on standard error and once in logs, preserves standard output, updates documentation, and passed all 30 tests.
• Proposed fix: Parse extraRepos into valid and invalid lists. Keep valid names, report invalid names on standard error, warn once per distinct invalid set, and document that wildcards do not work.
• Caveats: The source-level harness reproduced the CLI and log path. It did not test the real settings route, desktop 0.39.0, or a browser. The GitHub API returned UNKNOWN mergeability, but both local merge-tree checks passed.

The report has copy-paste repro steps, screenshots where the bug is visual, code permalinks at the base commit, and repro artifacts. It was independently re-run by a second agent (see its Verification section).

AGENT GENERATED: by GPT-5.6-Sol