Existing issues
What happened?
Description
Ollama (ollama.com) never shows real usage/pace data via the Web (cookie) source, even with a fully valid, currently-logged-in Brave session. The API-key source works but only returns a model-count placeholder ("N cloud models available", used_percent: 0.0), not real quota/Pace data — real usage requires the Web/cookie source per the README's provider matrix ("Ollama | Cookies / API Key | Usage, Cloud Models, Pace windows").
Verified independently of CodexBar (via curl, bypassing the app entirely) that the session is valid and the target page does contain real, parseable usage data server-rendered in the HTML:
GET https://ollama.com/settings with the browser's Cookie header → 200 OK, no sign-in redirect.- Page title:
Usage · Settings.
- Body contains exactly the markers the parser (
rust/src/providers/ollama/mod.rs::parse_usage_block) looks for: e.g. 0% used, width: 61.2%, Resets in 20 hours, ISO timestamps like 2026-09-07T00:00:00.
So the account, session, and HTML parser all check out — but CodexBar's own cookie source resolution never gets that header to the parser.
Root cause (as far as I could narrow it down)
Running codexbar-cli.exe -v usage --provider ollama --source web:
DEBUG codexbar::browser::cookies: Searching for cookies for domain ollama.com
DEBUG codexbar::browser::cookies: Found 3 cookies for ollama.com in Brave
— it finds exactly the 3 cookies the browser has for ollama.com (__Secure-session, __stripe_mid, aid) — __Secure-session is in OLLAMA_SESSION_COOKIE_NAMES (rust/src/providers/ollama/cookies.rs), so it should be recognized. But the fetch still fails immediately after with:
Error: No cookies available for web API
That's the Display string for ProviderError::NoCookies (rust/src/core/provider.rs:577). Tracing the call path in resolve_browser_cookie_header → ollama_cookie_header_for_url → cookie_applies_to_ollama_url, the only step between "3 raw cookies found" and "no recognized session cookie in the built header" is the per-cookie domain/path filter in cookie_applies_to_ollama_url. That strongly suggests the stored path (or domain) attribute on the real-world __Secure-session cookie doesn't satisfy that filter for the https://ollama.com/settings request URL, even though the cookie is valid and would obviously be sent by a real browser to that same URL.
Manually replaying the exact same 3-cookie header with curl against https://ollama.com/settings works perfectly (200, real usage data), which rules out the cookie/session itself and points at the filter in cookie_applies_to_ollama_url / ollama_cookie_header_for_url being stricter than an actual browser's cookie-matching rules.
Environment
- CodexBar version: 0.55.0 (build 90), also present on current
main
- OS: Windows 11
- Browser: Brave (cookie decryption itself works fine here — no App-Bound Encryption issue, unlike Chrome)
- Provider: Ollama, Web/cookie source, valid logged-in session
Steps to reproduce
- Log into
ollama.com in Brave.
codexbar-cli.exe -v usage --provider ollama --source web → observe Found 3 cookies for ollama.com in Brave immediately followed by Error: No cookies available for web API.- Copy the real
Cookie header for ollama.com from DevTools → Network → any request to ollama.com/settings.
curl -s -D - -o page.html "https://ollama.com/settings" -H "Cookie: <that header>" → 200 OK, page title Usage · Settings, body contains N% used, Resets in N hours, etc. — i.e., the exact data the parser wants, and the exact cookie CodexBar itself found for this domain.
Suggested fix direction
Loosen or re-check the per-cookie filter in cookie_applies_to_ollama_url (rust/src/providers/ollama/cookies.rs) — it looks like it's excluding a cookie a real browser would send. Might be worth logging the individual cookie name/path/domain triples (not just a count) at debug level so this class of mismatch is diagnosable without a manual curl replay.
Existing issues
What happened?
Description
Ollama (ollama.com) never shows real usage/pace data via the Web (cookie) source, even with a fully valid, currently-logged-in Brave session. The API-key source works but only returns a model-count placeholder (
"N cloud models available",used_percent: 0.0), not real quota/Pace data — real usage requires the Web/cookie source per the README's provider matrix ("Ollama | Cookies / API Key | Usage, Cloud Models, Pace windows").Verified independently of CodexBar (via
curl, bypassing the app entirely) that the session is valid and the target page does contain real, parseable usage data server-rendered in the HTML:GET https://ollama.com/settingswith the browser'sCookieheader →200 OK, no sign-in redirect.Usage · Settings.rust/src/providers/ollama/mod.rs::parse_usage_block) looks for: e.g.0% used,width: 61.2%,Resets in 20 hours, ISO timestamps like2026-09-07T00:00:00.So the account, session, and HTML parser all check out — but CodexBar's own cookie source resolution never gets that header to the parser.
Root cause (as far as I could narrow it down)
Running
codexbar-cli.exe -v usage --provider ollama --source web:— it finds exactly the 3 cookies the browser has for
ollama.com(__Secure-session,__stripe_mid,aid) —__Secure-sessionis inOLLAMA_SESSION_COOKIE_NAMES(rust/src/providers/ollama/cookies.rs), so it should be recognized. But the fetch still fails immediately after with:That's the
Displaystring forProviderError::NoCookies(rust/src/core/provider.rs:577). Tracing the call path inresolve_browser_cookie_header→ollama_cookie_header_for_url→cookie_applies_to_ollama_url, the only step between "3 raw cookies found" and "no recognized session cookie in the built header" is the per-cookie domain/path filter incookie_applies_to_ollama_url. That strongly suggests the storedpath(ordomain) attribute on the real-world__Secure-sessioncookie doesn't satisfy that filter for thehttps://ollama.com/settingsrequest URL, even though the cookie is valid and would obviously be sent by a real browser to that same URL.Manually replaying the exact same 3-cookie header with
curlagainsthttps://ollama.com/settingsworks perfectly (200, real usage data), which rules out the cookie/session itself and points at the filter incookie_applies_to_ollama_url/ollama_cookie_header_for_urlbeing stricter than an actual browser's cookie-matching rules.Environment
mainSteps to reproduce
ollama.comin Brave.codexbar-cli.exe -v usage --provider ollama --source web→ observeFound 3 cookies for ollama.com in Braveimmediately followed byError: No cookies available for web API.Cookieheader forollama.comfrom DevTools → Network → any request toollama.com/settings.curl -s -D - -o page.html "https://ollama.com/settings" -H "Cookie: <that header>"→200 OK, page titleUsage · Settings, body containsN% used,Resets in N hours, etc. — i.e., the exact data the parser wants, and the exact cookie CodexBar itself found for this domain.Suggested fix direction
Loosen or re-check the per-cookie filter in
cookie_applies_to_ollama_url(rust/src/providers/ollama/cookies.rs) — it looks like it's excluding a cookie a real browser would send. Might be worth logging the individual cookie name/path/domain triples (not just a count) at debug level so this class of mismatch is diagnosable without a manualcurlreplay.