Detect Ollama WorkOS sign-in redirects

[joeVenner]

Summary

• detect Ollama /signin redirects before attempting usage parsing
• recognize the WorkOS AuthKit authorization destination on any *.workos.com host carrying the /user_management/authorize path
• treat the WorkOS-hosted signin.ollama.com terminal landing as an expired session (previously fell through to a parse failure)
• surface expired-session recovery (invalidCredentials) so CodexBar advances to the next cookie candidate instead of a misleading parser failure

Live runtime proof

A live probe linked against CodexBarCore drove the real OllamaUsageFetcher against https://ollama.com/settings with a synthetic (invalid) session cookie and a redirect logger. No real account or secret was used; the captured chain is the real unauthenticated Ollama/WorkOS sign-in flow, and the fetcher now surfaces invalidCredentials (previously parseFailed):

$ swift test --disable-sandbox --filter LiveOllamaWorkOSProbe
isSignInRedirect(api.workos.com/user_management/authorize) = true
isSignInRedirect(signin.ollama.com) = true
[ollama] Cookie names: __Secure-next-auth.session-token, theme
[ollama] Redirect 303 https://ollama.com/settings -> https://ollama.com/signin
[ollama] Redirect 303 https://ollama.com/signin -> https://api.workos.com/user_management/authorize?client_id=...&provider=authkit&redirect_uri=...&response_type=code
[ollama] Redirect 302 https://api.workos.com/user_management/authorize?... -> https://signin.ollama.com/?client_id=...&authorization_session_id=01KWWZQSHD97Z68ECE3K52G516
[ollama] Redirects:
[ollama]   303 https://ollama.com/settings -> https://ollama.com/signin
[ollama]   303 https://ollama.com/signin -> https://api.workos.com/user_management/authorize?...
[ollama]   302 https://api.workos.com/user_management/authorize?... -> https://signin.ollama.com/?client_id=...
RESULT: fetch threw -> invalidCredentials          # now expired-session recovery, not parseFailed
✔ Test run with 2 tests in 2 suites passed after 1.673 seconds.

The real chain is ollama.com/settings → /signin → api.workos.com/user_management/authorize → signin.ollama.com (HTTP 200). All three sign-in surfaces are now classified as sign-in redirects: /signin on ollama.com, the WorkOS *.workos.com/user_management/authorize intermediate hop, and the signin.ollama.com terminal landing — so the fetcher throws invalidCredentials and CodexBar can advance to the next cookie candidate / show sign-in guidance instead of a confusing Missing Ollama usage data parse error.

Note for the maintainer

The broadened *.workos.com host match survives WorkOS host changes/CNAMEs; the previous exact host == "api.workos.com" match would miss auth.workos.com. No CHANGELOG entry is included (release-owned); the maintainer can credit @joeVenner at release time as with the merged Ollama follow-ups. No live authenticated account was available, so the expired-session recovery path is the real-runtime proof; the injected-transport test suite (20 tests) covers the matcher cases deterministically, including auth.workos.com, api.workos.com, signin.ollama.com, and an example.com negative case.

Testing

• swift test --disable-sandbox --filter OllamaUsageFetcherTests (20 passed, incl. signin.ollama.com terminal-landing case)
• live probe above against the real ollama.com / WorkOS sign-in flow (1.67s) → invalidCredentials
• swift build clean

[joeVenner]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 7, 2026, 6:33 AM ET / 10:33 UTC.

Summary
The PR classifies Ollama WorkOS sign-in redirect destinations as expired-session redirects, adds focused tests and docs, and includes a maintainer-authored release-note entry on the latest head.

Reproducibility: yes. source-reproducible with PR proof: current main follows a 200 final response into parsing, while the PR body captures the real Ollama/WorkOS chain ending at signin.ollama.com and the latest head returning invalidCredentials. I did not run the live probe because repository policy avoids live provider probes unless explicitly requested.

Review metrics: 2 noteworthy metrics.

• Changed surface: 5 files, +112/-7. The PR is bounded to one provider fetcher, focused provider tests, provider docs, and a release-note line.
• Proof target: 1 live-output transcript. The PR body shows the real unauthenticated Ollama/WorkOS redirect chain ending in invalidCredentials after the change.

Merge readiness
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Risk before merge

• [P1] Required CI jobs were still pending at inspection time, so merge should wait for the normal check gate to finish.

Maintainer options:

1. Decide the mitigation before merge
   Land the narrow provider fix after maintainer review and required checks pass, keeping redirect classification scoped to known Ollama and WorkOS sign-in surfaces.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• [P2] No repair is queued because I found no actionable patch defect; the remaining action is ordinary maintainer review and check gating.

Security
Cleared: The diff only changes Ollama provider URL classification, focused tests, docs, and release-note context; I found no concrete security or supply-chain concern.

Review details

Best possible solution:

Land the narrow provider fix after maintainer review and required checks pass, keeping redirect classification scoped to known Ollama and WorkOS sign-in surfaces.

Do we have a high-confidence way to reproduce the issue?

Yes, source-reproducible with PR proof: current main follows a 200 final response into parsing, while the PR body captures the real Ollama/WorkOS chain ending at signin.ollama.com and the latest head returning invalidCredentials. I did not run the live probe because repository policy avoids live provider probes unless explicitly requested.

Is this the best way to solve the issue?

Yes. The final-response URL classifier is a narrow fix, the latest maintainer commit preserves non-200 network errors, and focused tests cover the observed terminal landing plus negative cases.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 30ae39a7ee83.

Label changes

Label justifications:

• P2: This is a bounded Ollama provider auth-handling bug fix with limited blast radius.
• rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes copied live probe output against the real unauthenticated Ollama/WorkOS redirect chain showing the new invalidCredentials result, with no real account secret used.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes copied live probe output against the real unauthenticated Ollama/WorkOS redirect chain showing the new invalidCredentials result, with no real account secret used.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its guidance to prefer focused provider/parser tests and avoid unsolicited live provider probes shaped the review. (AGENTS.md:1, 30ae39a7ee83)
• Current main behavior: Current main records the final response URL, checks only HTTP status, and then parses the HTML, so a 200 sign-in landing can fall through to parser failure. (Sources/CodexBarCore/Providers/Ollama/OllamaUsageFetcher.swift:529, 30ae39a7ee83)
• PR implementation: The PR maps a 200 final response URL recognized as an Ollama/WorkOS sign-in redirect to OllamaUsageError.invalidCredentials before parsing. (Sources/CodexBarCore/Providers/Ollama/OllamaUsageFetcher.swift:535, c571a0cea3ac)
• Redirect matcher coverage: The matcher tests cover /signin, api.workos.com, auth.workos.com, signin.ollama.com, non-settings WorkOS paths, non-HTTPS URLs, and non-WorkOS hosts. (Tests/CodexBarTests/OllamaUsageFetcherTests.swift:35, c571a0cea3ac)
• Fetch-path coverage: The retry-mapping tests verify that a 200 signin.ollama.com landing surfaces invalidCredentials and that a sign-in host returning 503 remains a network error. (Tests/CodexBarTests/OllamaUsageFetcherRetryMappingTests.swift:143, c571a0cea3ac)
• Provider docs: The Ollama docs now explain that settings redirects to /signin or WorkOS AuthKit authorization are treated as expired sessions so CodexBar can try the next cookie candidate. (docs/ollama.md:44, c571a0cea3ac)

Likely related people:

• steipete: Authored the latest hardening commit on this PR and recently touched the Ollama fetcher in release work. (role: recent area contributor; confidence: high; commits: c571a0cea3ac, a83a83fa4131; files: Sources/CodexBarCore/Providers/Ollama/OllamaUsageFetcher.swift, Tests/CodexBarTests/OllamaUsageFetcherTests.swift, CHANGELOG.md)
• joeVenner: Authored the merged WorkOS cookie support commit that this redirect handling builds on, so they have current-main history in the same provider area beyond this PR. (role: recent adjacent contributor; confidence: medium; commits: 30ae39a7ee83, 785f6957024f; files: Sources/CodexBarCore/Providers/Ollama/OllamaUsageFetcher.swift, Tests/CodexBarTests/OllamaUsageFetcherTests.swift, docs/ollama.md)
• Ratul Sarna: History shows multiple earlier commits hardening Ollama manual cookie handling, auth detection, and retry mapping in the same provider. (role: Ollama auth and retry contributor; confidence: high; commits: e006d1a023a0, b58c62e0f875, 32ffc9fd9e4b; files: Sources/CodexBarCore/Providers/Ollama/OllamaUsageFetcher.swift, Tests/CodexBarTests/OllamaUsageFetcherTests.swift)
• CryptoSageSnr: The Ollama provider source, initial tests, and provider docs appear to date to the original Ollama provider support commit. (role: introduced provider baseline; confidence: medium; commits: 27c1bb95770b; files: Sources/CodexBarCore/Providers/Ollama/OllamaUsageFetcher.swift, Tests/CodexBarTests/OllamaUsageFetcherTests.swift, docs/ollama.md)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (10 earlier review cycles; latest 8 shown)

• reviewed 2026-07-06T21:14:29.361Z sha a503b1a :: needs real behavior proof before merge. :: none
• reviewed 2026-07-06T21:19:48.689Z sha a503b1a :: needs real behavior proof before merge. :: none
• reviewed 2026-07-06T21:31:11.257Z sha a503b1a :: needs real behavior proof before merge. :: none
• reviewed 2026-07-06T22:02:55.646Z sha d76fbc7 :: needs real behavior proof before merge. :: [P2] Remove the release-owned changelog entry
• reviewed 2026-07-07T00:00:39.331Z sha d76fbc7 :: needs real behavior proof before merge. :: [P2] Handle the observed terminal sign-in landing | [P2] Remove the release-owned changelog entry
• reviewed 2026-07-07T00:08:14.208Z sha d76fbc7 :: needs real behavior proof before merge. :: [P2] Handle the terminal sign-in landing | [P2] Remove the release-owned changelog entry
• reviewed 2026-07-07T00:30:25.057Z sha c5945ae :: needs real behavior proof before merge. :: [P2] Handle the terminal sign-in landing
• reviewed 2026-07-07T02:35:33.478Z sha 9f25aeb :: needs maintainer review before merge. :: none

[joeVenner]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[joeVenner]

@clawsweeper re-review

[joeVenner]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[joeVenner]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[joeVenner]

@clawsweeper re-review

[joeVenner]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[joeVenner]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[joeVenner]

@clawsweeper re-review

[joeVenner]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[steipete]

Maintainer verification on exact head c571a0cea3aca56f8f9cae45f2854594e45596cb:

• Public Model Identifier Gate: PASS (no model identifiers added or changed).
• Root cause: Ollama's expired WorkOS session flow follows redirects to a 200 sign-in page; the fetcher previously parsed that HTML as usage and surfaced Missing Ollama usage data instead of an authentication error.
• Repair: classify successful HTTPS Ollama/WorkOS sign-in landings as invalidCredentials, allowing the existing cookie-candidate retry path. Non-200 sign-in service failures remain network errors.
• Focused: 31 tests passed across OllamaUsageFetcherTests and OllamaUsageFetcherRetryMappingTests, including injected-session coverage for a 200 sign-in landing and a 503 service failure.
• Quality: make check passed (SwiftFormat clean; SwiftLint 0 violations).
• Full suite: make test passed all 49 shards / 584 selections in 255s.
• Autoreview: clean, no accepted/actionable findings (0.97 confidence).
• Runtime: the PR's secret-free live probe exercised the real unauthenticated Ollama → WorkOS → signin.ollama.com chain and changed the surfaced result from parseFailed to invalidCredentials.
• Review: zero unresolved review threads; no dependency changes.
• Exact-head CI: changes, lint, security, Linux arm64, and Linux x64 passed. Hosted macOS shards remained capacity-queued; landing uses the documented capacity-only policy backed by the complete local macOS suite above.

Patch surface: 5 files, +112/-7. The change is isolated to Ollama response classification, focused tests, provider docs, and changelog credit for @joeVenner.