[DreamyTalesPAN]

Ziel

Windows-Kunden mit zwei Claude-Konten sehen dieselben Werte wie auf dem Mac: das im VibeTV-Claude-Fenster angemeldete Konto gewinnt vor einem angemeldeten Claude Code (VibeTV-shop/vibetv#273, Folge von nesszer#244).

Ursache

fetch_via_auto (Claude) fragt Admin-API → Claude-Code-OAuth → (Web nur ohne Claude-Code-Login) → CLI → Web. serve läuft immer mit SourceMode::Auto, der Companion kann die Quelle nicht wählen. Die Anmeldung aus dem VibeTV-Fenster kommt als CLAUDE_AI_SESSION_KEY in die Umgebung des Engine-Laufs (Companion, withWindowsClaudeSession); Auto antwortete trotzdem zuerst aus Claude Code.

Änderung (8 Zeilen + 1 Test)

• fetch_via_auto: ist CLAUDE_AI_SESSION_KEY (bzw. CLAUDE_WEB_SESSION_KEY) gesetzt, wird nur fetch_via_web gelesen und dessen Ergebnis oder Fehler zurückgegeben. Kein OAuth-, CLI- oder Browser-Rückfall. Eine abgelaufene Fenster-Anmeldung bleibt „Authentication required" (der Companion zeigt das schon als Anmeldung) statt still das Konto von Claude Code zu zeigen.
• Der Admin-API-Schlüssel bleibt davor (bewusst vom Kunden gesetzt, andere Art Konto).
• Keine neue Provider-Bedeutung, kein Companion-Code nötig.
• Test auto_with_a_window_session_returns_only_the_web_error (web_api.rs): vor dem Fix rot (Auto lieferte das Ergebnis der Claude-CLI dieses Rechners), danach grün.

Gestapelt

Basis ist claude/289-c (#16), das auf claude/missing-data-no-zero (#15) aufbaut. Bitte erst #15 und #16 mergen; GitHub zieht die Basis dann nach.

Tests

cargo test: 1971 grün, 4 rot — dieselben vier Windows-Pfad-Tests (pi_family ×2, codex_sessions::normalizes_codex_root_to_sessions_dir, core::hooks::tests::config_matching_respects_enabled_flag), die auf macOS auch ohne diese Änderung rot sind. Alle 156 Tests unter providers::claude grün. Geprüft auf macOS; Windows-Lauf folgt mit dem Release über die VibeTV-Rehearsals.

Bitte an Marcus

Mergen und Tag schneiden: nächste Nummer nach .15 (v0.60.3-vibetv.16), oder zusammen mit .15 — das entscheidest du. Danach bumpt VibeTV den Pin (scripts/fetch-win-codexbar.ps1).

🤖 Generated with Claude Code

[DreamyTalesPAN]

Tracking issue VibeTV-shop/vibetv#296, pin draft VibeTV-shop/vibetv#297 (waits for your tag: .16 or folded into .15, your call). Nothing in #15/#16 has to change for this.

[DreamyTalesPAN]

Gestapelt auf #16: Merge-Commit 0c5def4d zieht den neuen #16-Head f327cfcb nach (kein Konflikt, kein Force-Push). cargo test -p codexbar unverändert: nur die 4 bekannten Windows-Pfad-Tests rot.

[marcus7989]

W182 review: ohne Befund (no P1/P2 findings) on 0c5def4d9bd8b33595e0e1059f7dab46909dfda2, against #16 (f327cfcb).

With a non-empty CLAUDE_AI_SESSION_KEY or CLAUDE_WEB_SESSION_KEY, Auto directly returns the web result/error before OAuth, CLI, browser-cookie or cached-CLI fallback. Web resolution also returns directly from the environment-key branch. The existing explicit Admin API priority is preserved, as documented in this PR; without a resolved environment key the existing Auto sequence is unchanged. Companion /usage supplies no manual-cookie override.

An additional isolated probe exercised both key variants with a forced local connection failure and a populated CLI cache: the web error wins, no OAuth/CLI attempt is logged, and neither fake key appears in error text or captured TRACE logs. Empty/whitespace-only key values remain unresolved. Source review confirms the key is used in the Cookie header, not interpolated into logging; HTTP errors expose status rather than response body or cookie.

Local cargo test -p codexbar --jobs 2: 1992 passed, 4 known macOS Windows-path failures, 1 ignored. Re-running with exactly those four tests excluded passes: 1992 library tests + 1 binary test, no failures. Formatting and diff whitespace checks pass. Native two-account/expired-session Companion validation is still required on Windows.

Recommendation: bundle #17 with #16 in v0.60.3-vibetv.15, provided that tag is still unused when approved. One tested engine/Companion pair and one pin avoids an interim release retaining the wrong-account behavior. This comment does not authorize merge, tag or device use.

[DreamyTalesPAN]

Joint Windows probe of #15–#17: PASS (details below; same text on all three PRs).

Build: local merge branch claude/probe-15-17 @ 8b8134d3 (#15 53941bcc + #16 cacb7c8d + #17 0c5def4d; clean merge, branch only, no PR). Built on a Windows runner like the release build (cargo build --release --bin codexbar, Rust 1.98.0, static CRT): codexbar 0.60.3, codexbar-cli.exe sha256 a7b3f8e95bee92f3e831159838365becb8366696e32987ba6c48350b25fe6ed8.
Windows unit tests (cargo test -p codexbar --lib, windows-latest): 2035 passed, 1 failed. The 4 path tests that fail on macOS pass on Windows. The one failure is codex_accounts::codex_desktop::tests::restart_uses_manifest_gui_and_leaves_standalone_cli_alone (it runs a PowerShell restart script on the runner); codex_accounts/ is identical to vibetv, so none of #15–#17 touches it. I did not re-run it on plain vibetv.
VibeTV app on real Windows (bench laptop, real VibeTV on the cable): CI installer 9999.0.357 (merge commit of VibeTV main 5c97812c), its codexbar-cli.exe replaced by the probe CLI after each install (sha verified).

• Cold (from delivery firmware 1.0.41): paired, firmware 1.0.50, Mini Classic active, renderOk: true, stream healthy.
• Warm (public 1.0.66 + 1.0.50, candidate installed over it): app 9999.0.357, still paired, theme kept, stream healthy, Updates tab "Up to date".
  Direct CLI comparison, .13 vs probe (real Claude Max login, settings copied, nothing written to the app's config):
• usage --provider claude without a session key: identical windows and numbers (probe adds usageKnown: true on the window); real values, no invented 0 %.
• Claude Auto: the Claude window's session key reads only claude.ai, a signed-in Claude Code does not win (VibeTV-shop/vibetv#273) #17: with an invented CLAUDE_AI_SESSION_KEY, .13 still answers from Claude Code (source: oauth, real numbers); the probe answers only {"error":"Authentication required","provider":"claude"}.
  Not covered: live provider answers that arrive without a usable quota (Report missing provider usage as unavailable instead of an invented 0% (VibeTV #285) #15/Remove the remaining invented 0 % / window values (VibeTV #289) #16) need accounts we do not have; that part rests on the fork's red-to-green unit tests (all pass on Windows). The same applies to the Kimi K2 and Doubao cases of the Remove the remaining invented 0 % / window values (VibeTV #289) #16 fix. The real claude.ai sign-in in the VibeTV window was not exercised, only the environment variable path. Fork CI (CircleCI) reported no status on the new Remove the remaining invented 0 % / window values (VibeTV #289) #16 head.

Ready for your merge, then tag .14 for #15 and .15 for #16 + #17?

[marcus7989]

W211 · Beelink Windows validation, 2026-10-29 · STOP (environment blocker)

The exact native Rust 1.98.0 baseline/probe comparison could not start: HOMESTATION-WIN has no cargo/rustc/rustup on PATH, no user .cargo/.rustup directory, and no matching Rust/MSVC/Git executables in the checked tools/program directories. No compiler/toolchain was installed during this slot. This is an unfulfilled test environment, not an observed product regression; no cargo test exit codes exist and the known restart-test result remains unresolved.

Task results: (1) baseline 7614e4d vs probe 8b8134d BLOCKED before execution; (2) isolated #15 / .14 build and VibeTV smoke NOT RUN; (3) automatic Windows Usage/Refresh NOT RUN after the explicit stop condition; (4) NO MERGES, NO TAGS, no release workflow triggered.

Final baseline check passed: app 9999.0.2266, runtime a9e985be9d1500de8455edc26d62c9a66b52bd4f, VibeTV 5804558, Clippy, brightness 20, automatic codex/claude/cursor. All app files and 13/13 configs match the pre-slot backup byte-for-byte; Firefox process IDs and existing Codex CLI auth-file hash are unchanged. No login, reboot or OS switch performed. Current PR heads remain #15 53941bc, #16 cacb7c8, #17 0c5def4.

Local evidence: .local/reports/wincb16/BEELINK-W211.md; w211/tools-result.json and w211/final-result.json. The next native run needs a prepared Rust 1.98.0/MSVC build environment, or a separately approved cross-build/native-execution plan; it must not be reported as already tested.