[Feature]: CLI parity so embedding apps can use official releases (enabled-provider usage, JSON inventory, consent flag, serve timeout, CODEXBAR_CONFIG, sign-in marker)

[marcus7989]

Existing issues

• I searched existing issues and did not find a duplicate.

Problem or use case

We build VibeTV, a small desk display that shows AI usage limits. On macOS our companion app runs the upstream CodexBarCLI headlessly. On Windows it runs the Win-CodexBar console CLI (codexbar.exe) the same way.

To ship on Windows we had to pin a small fork (marcus7989/Win-CodexBar, tag v0.60.3-vibetv.3), because a few CLI behaviours differ from the macOS CLI or are missing. We would like to go back to your official releases and stop maintaining the fork. This is what stands in the way, checked against main at b585d488:

1. Plain usage only asks Claude. ProviderSelection::from_arg(None) defaults to Claude. --provider all walks every provider (~70) whether it is enabled or not, and does not finish in a reasonable time. On macOS, a plain usage --json returns every enabled provider. Today we read the inventory and query each enabled provider one at a time.
2. config providers has no JSON output. The macOS CLI has config providers --json, so we parse the text lines.
3. No CLI switch for claude_allow_reading_claude_code_credentials, the consent toggle from fix(claude): add missing UI toggle for Claude Code credentials consent #348. We edit settings.json directly.
4. serve has no --request-timeout. macOS: codexbar serve --request-timeout <seconds>.
5. CODEXBAR_CONFIG is ignored. On macOS it overrides the config path, which isolated test runs and embedding apps rely on.
6. Windows Claude /usage PTY probe is flaky. On several Windows 10/11 machines the first /usage keystrokes are lost because Claude Code's input widget mounts later. The fixed --session-id then fails with "already in use", and two codexbar processes (serve plus a one-off usage) collide. PR attached.
7. Gemini OAuth refresh finds no client constants with current Gemini CLI npm releases. They ship one esbuild bundle (@google/gemini-cli/bundle/chunk-*.js) and no longer include gemini-cli-core/dist, so refresh fails unless the env vars are set. PR attached.
8. No machine-readable "browser sign-in needed" signal for Claude. This is the case where the OAuth usage endpoint answers 429, no claude.ai cookies can be read, and the CLI probe fails too. Our fork appends [claude:browser-sign-in-required https://claude.ai/login] to the Auto-mode summary so we don't have to parse English text. A typed error kind in the JSON error payload would be even better.

Proposed solution

• Items 6 and 7 come with focused PRs (linked below).
• Items 1-5 and 8 are small. If you agree with the direction, we can send each as a separate small PR. Please tell us which ones you would accept and in which shape. For item 1, for example: should plain usage default to enabled providers, or should there be a new --provider enabled?

Affected area

• CLI
• Provider-specific behavior
• Config file / settings persistence

Alternatives considered

Keeping our fork. It works, but it falls behind your provider ports (for example #633) and duplicates your work.

Additional context

• On macOS we pin upstream CodexBar, where items 1-5 exist.
• Thanks for the port. The provider coverage is the reason we want to stay on your releases.

[marcus7989]

PRs for items 6 and 7: #641 (Windows Claude /usage probe) and #642 (Gemini OAuth constants from the bundled CLI).

[Finesssee]

Thanks for the report, I will look into it.