[DreamyTalesPAN]

Two options of CodexBar's Mac CLI that this CLI rejected, which VibeTV works around on Windows (DreamyTalesPAN/CodexBar-Display#437).

config providers --json prints the provider list as an array of {provider, displayName, enabled, defaultEnabled}. --format text|json and --pretty are accepted. The text form is unchanged.

serve --request-timeout <seconds> answers 504 Gateway Timeout ({"error":"request timed out"}) when a request is still unanswered after that time. The work keeps running, so a slow dashboard snapshot is cached and the next request gets it. 0 means no deadline. Difference from upstream: the default is 0, not 30, so the server behaves as before when the option is absent.

What a release changes for VibeTV: nothing until the product pins it. After the pin, the product's release contract test (released_cli_test.go with CODEXBAR_CONTRACT_KNOWN_GAPS=1) fails on purpose for both options; the product then drops the Windows text inventory and passes --request-timeout 0 on Windows too, and removes the two entries from its "Known dependency gaps".

Checked. Unit tests for the JSON shape against the Mac recording, the option parsing, the 504, and the cached build after a 504 (cli:: 167). Cross-built on a Mac and run on the Windows test laptop on 2026-10-08: serve --help lists --request-timeout, serve … --request-timeout 0 starts and answers, config providers --json prints the array. Not run: cargo clippy, the full test suite.

🤖 Generated with Claude Code

[marcus7989]

Querverweis zu #11: Dort werden CODEXBAR_CONFIG, usage --provider enabled, config claude-consent und cost --refresh umgesetzt, unabhängig von diesem PR.

Hinweis für die Companion-Umstellung (DreamyTalesPAN/CodexBar-Display#437): In diesem PR ist serve --request-timeout eine Antwortzeit. Nach Ablauf antwortet der Server mit 504, 0 wartet. Der Companion-Umweg in nesszer#437 muss das beim Entfernen beachten und darf den Wert nicht als Fetch-Timeout lesen.

[DreamyTalesPAN]

@marcus7989 Question from the VibeTV side (issue DreamyTalesPAN/CodexBar-Display#437): is this PR ready to merge? If yes, could you merge it together with #11 and tag a new release (e.g. v0.60.3-vibetv.12)? We would then raise the pin in scripts/fetch-win-codexbar.ps1 and remove the Companion detours (runUsageAllEnabled, the text parser, the CODEXBAR_CONFIG workaround, --request-timeout) in a PR from our side.

[marcus7989]

Thanks, Paul. We are checking #9 and #11 together right now, including whether they merge cleanly, since both touch rust/src/cli/config.rs. We will get back to you with the result. We have not pushed anything to this PR.

[marcus7989]

Hi Paul, release v0.60.3-vibetv.13 is out as a pre-release (PRs #9, #11 and #12 merged into vibetv).

• Release: https://github.com/marcus7989/Win-CodexBar/releases/tag/v0.60.3-vibetv.13
• Tag v0.60.3-vibetv.13 points to commit 7614e4d (vibetv head).
• Asset: CodexBarCLI-v0.60.3-vibetv.13-windows-x64.zip
• SHA256 of the zip: a7ccaed79e4fcba5cb0f7a60f1f580fafee8543f39eb93907378373edcd35edd

Please use this tag and SHA256 for your pin PR. Two notes for it:

1. released_cli_test.go (CI, with CODEXBAR_CONTRACT_KNOWN_GAPS=1) fails once the pin includes cli: config providers --json and serve --request-timeout #9, so the known-gap workaround there needs updating.
2. PR config: list removed providers only while they are enabled #6 (removed providers hidden on Windows, [0.60.5] Preserve Antigravity history with foreign databases nesszer/Win-CodexBar#547) is not in this release yet. It follows with your pin PR once the branch question in config: list removed providers only while they are enabled #6 is answered.

A Windows test of the combined state including #12 is still pending.