fix(cli): usage silently ignores unknown --provider values

Aperta Adatta ai principianti
  • Qualcosa non va?
#5,017 1 commento 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@harjothkhara ci sta già lavorando.

Dal 7/11/2026.

  • #5019 di @harjothkhara — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
74/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
swift
Ambito
cli

Direzione di ricerca

Leggi Sources/CodexBarCLI/CLIHelpers.swift, in particolare decodeProvider e providerSelection, poi segui il percorso di ingresso documentato attraverso CLIEntry.main e runUsage. Controlla i test esistenti sulla selezione del provider per le sovrascritture valide e i valori predefiniti quando l’opzione è omessa. Il lavoro è completato quando un provider esplicito sconosciuto restituisce un errore di argomento con codice diverso da zero, mentre le opzioni omesse, i nomi validi, gli alias, both e all mantengono il comportamento supportato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:auth-provider issue-rating: 🦞 diamond lobster no-stale P2

Summary

codexbar usage --provider not-a-real-provider accepts an unknown name and silently uses the enabled-provider defaults. With successful enabled providers, this can return other providers' usage with exit status 0, so a script cannot rely on success to mean that its requested provider was recognized. With no enabled providers, the same invalid selection returns an empty array and exit status 0.

Runtime or environment

  • Latest published release: CodexBar 0.84.0, tested using the official standalone macOS arm64 CLI archive with its published SHA-256 verified. The original supplied observation used the Homebrew app's bundled CLI.
  • Default branch: main at e66b0d6981ab1ac4fa565a69b86c89a401e49305, freshly cloned and built with swift build --product CodexBarCLI --jobs 3.
  • Local platform: macOS 27.2, arm64; Apple Swift 6.4 for the source build.

Steps to reproduce

The following isolated case was executed against both tested builds. It requires no account credentials and enables no provider fetches. Set cli to either tested executable's absolute path, then run:

taskHome=$(mktemp -d /tmp/codexbar-provider.XXXXXX)
cat > "$taskHome/config.json" <<'JSON'
{"version":1,"providers":[{"id":"codex","enabled":false},{"id":"claude","enabled":false}]}
JSON

env -i HOME="$taskHome" CFFIXED_USER_HOME="$taskHome" \
  XDG_CONFIG_HOME="$taskHome/config" CODEXBAR_CONFIG="$taskHome/config.json" \
  CODEXBAR_DISABLE_KEYCHAIN_ACCESS=1 PATH=/usr/bin:/bin TMPDIR="$taskHome" \
  "$cli" usage --provider not-a-real-provider --format json
printf 'exit status %s\n' "$?"

As a control, repeat without --provider not-a-real-provider. As an argument-validation control, add --source bogus to the invalid-provider invocation.

Expected behavior

The usage help advertises a finite provider-name list plus both|all. A supplied name outside that selection should produce an argument error and a nonzero exit status instead of selecting the defaults. Omitting the option should continue to use enabled providers.

Actual behavior

Both tested builds return the same result with the invalid provider and with the provider option omitted:

[]
exit status 0

The invalid-source control returns a CLI argument error containing --source must be auto|web|cli|oauth|api. and exit status 1 on both builds.

The supplied bundled-release observation, with Codex and Claude enabled and working, was:

$ CodexBarCLI usage --provider not-a-real-provider --format json | jq -c '[.[].provider]'
["codex","claude"]
exit status 0

Only provider names and exit status are reproduced here; no account usage or identities are included. I independently reproduced invalid-name acceptance and success status in the isolated case; the nonempty account-backed result above is supplied evidence, not a live-account rerun.

Evidence

The current entry path is CLIEntry.main → runUsageDisplay → runUsage → decodeProvider → providerSelection. ProviderSelection.init(argument:) returns nil for an unregistered name, and the helper does not distinguish that result from an absent override. runUsage then fetches its resulting provider list. The inspected provider-selection tests cover valid overrides, aliases, and omitted-option defaults; they do not define unknown-name fallback as intended. I found no such fallback contract in the CLI documentation.

Restoration check

Repeat the isolated invalid-name invocation: it should return a nonzero argument error identifying the unrecognized selection. The omitted-option control should still return [] successfully for that fixture. With configured working providers, the invalid-name invocation must not return their usage as if the requested provider had been selected. Valid names, documented aliases, both, and all should retain their supported selection behavior.

References

Closed PR #830 concerns an older enabled-provider expansion defect. This report concerns an explicitly supplied unknown provider being treated as an omitted option; the current source and both tested binaries still exhibit that behavior.

Triage assessment

  • Impact level: P2
  • Assessment status: supported
  • Impact basis: An invalid explicit provider selection silently changes the requested scope and can report unrelated providers' usage with success; the isolated case also demonstrates false success without credentials. The demonstrated failure is bounded to unknown provider names.
  • Workaround status: available
  • Workaround basis: Use the built-in name or documented alias from usage help; the existing provider-selection test verifies that a recognized explicit override selects that provider. Scripts can validate the requested name and returned provider IDs instead of treating exit status alone as selection validation.
Lingua principale
Swift
Stelle
23.1k
Fork
2.2k
Merge medio
1g 4h
PR unite (30g)
386

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di steipete/CodexBar

Tutte le issue di steipete/CodexBar

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.