Skip to content

config: list removed providers only while they are enabled - #6

Open
DreamyTalesPAN wants to merge 1 commit into
marcus7989:vibetvfrom
DreamyTalesPAN:claude/hide-removed-providers
Open

DreamyTalesPAN wants to merge 1 commit into
marcus7989:vibetvfrom
DreamyTalesPAN:claude/hide-removed-providers

Conversation

@DreamyTalesPAN

Copy link
Copy Markdown
Collaborator

Problem (DreamyTalesPAN/CodexBar-Display#547): the VibeTV Windows app lists every provider that codexbar config providers prints. That command prints one row per ProviderId::all(), so the list contains the two retired providers as kimik2: disabled (Kimi K2 (removed)) and crossmodel: disabled (CrossModel (removed)). A VibeTV customer is offered both rows.

Rule now (rust/src/cli/config.rs): config providers follows the rule the settings UI already uses for ProviderId::is_deprecated() ("Settings UI hides them unless already enabled in settings", rust/src/core/provider.rs). A deprecated provider is listed only while it is switched on in the settings; otherwise it is left out. The selection moved into a small pure function, listed_providers(&Settings) -> Vec<ProviderId>, which list_providers() iterates. Order and row format are unchanged.

Not changed: ProviderId::all(), ProviderId::from_cli_name (so --provider kimik2, config enable kimik2 etc. keep resolving), the usage and cost commands, the settings UI. One file, +45 / -5.

Validation (macOS host, Rust 1.98.0 from scripts/circleci-pinned-rust.txt)

  • cargo fmt --all -- --check: clean.
  • cargo test -p codexbar --lib cli::config: 5 passed, 0 failed (2 new, 3 existing; the module's fourth existing test is #[cfg(windows)] and is not compiled on macOS).
    • listed_providers_hides_deprecated_providers_by_default: with Settings::default() neither KimiK2 nor CrossModel is listed, and every provider of ProviderId::all() is listed exactly when it is not deprecated.
    • listed_providers_keeps_deprecated_provider_enabled_in_settings: after enable_provider(KimiK2), KimiK2 is listed and CrossModel still is not.
    • With the filter switched off both new tests fail (assertion failed: !listed.contains(&ProviderId::KimiK2) / ...CrossModel).
  • The built CLI, run against an empty config directory (HOME pointed at a scratch folder): config providers prints 69 rows instead of 71 and none contains removed. After config enable kimik2 it prints 70 rows including kimik2: enabled (Kimi K2 (removed)); after config disable kimik2 the row is gone again.

Not run: the full test suite, cargo clippy (on macOS it already fails on an untouched vibetv), this repo's Windows CI, an MSVC build, the Windows-only test of the module, and the VibeTV Windows app against the new engine.

After merge: VibeTV picks this up with the next engine release and the pin bump in scripts/fetch-win-codexbar.ps1 of CodexBar-Display.

🤖 Generated with Claude Code

`config providers` printed one row per ProviderId::all(), including the
two soft-removed providers as "Kimi K2 (removed)" and "CrossModel
(removed)". The VibeTV Windows app builds its provider list from that
output, so a customer was offered both rows
(DreamyTalesPAN/CodexBar-Display#547).

The command now follows the rule the settings UI already uses for
ProviderId::is_deprecated(): a deprecated provider is listed only while
it is enabled in settings. Resolving the names (`--provider kimik2`,
`config enable kimik2`) is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@marcus7989

Copy link
Copy Markdown
Owner

Question for @DreamyTalesPAN from the VibeTV side (issue DreamyTalesPAN/CodexBar-Display#547).

This PR is based on vibetv from 07.10. It is 1 commit ahead and 6 behind, and only rust/src/cli/config.rs changed. I want to bring it up to date and test it on the Windows test laptop.

Please answer with 1 or 2:

  1. I update this branch by merging the current vibetv into it. No force push, your commit stays as it is.
  2. I leave this branch alone and open a new codex/ branch with the same change.

Also: PR #9 (claude/cli-parity) changes rust/src/cli/config.rs too, so one of the two PRs needs a merge. Which order do you want, or should #6 wait for #9?

Until you answer I do not push to this branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants