Improve DeepSeek detailed usage

[Zihao-Qi]

Summary

• enrich the existing DeepSeek balance with today/current-month cost and token totals, request counts, model/category breakdowns, and a 30-day token chart
• discover DeepSeek Platform sessions from Chrome local storage, validate every discovered profile, and offer only valid profiles in Settings
• keep the balance and profile selector stable while detailed usage refreshes or a profile changes
• scope each profile choice to the active API credential and saved-account slot to prevent cross-account data mixing
• bound optional Platform work so a slow or uncooperative browser/session probe cannot delay the required balance

Why

DeepSeek's documented API exposes the account balance but not the detailed usage visible at platform.deepseek.com/usage. The Platform dashboard uses private endpoints for that data.

This change keeps the documented balance fetch authoritative and required. Platform usage is optional enrichment: failures, invalid sessions, and timeouts preserve the balance instead of failing the provider.

Compared with #1910

This builds on the same general idea of reading DeepSeek Platform usage, but uses a narrower and more defensive session path:

• reads the Platform userToken from live Chrome local storage instead of relying on cookies or persisting a manual browser token
• discovers all Chrome profiles and validates each session before showing it
• lists only valid profiles and requires an explicit choice for a new or changed API credential
• fingerprints the API credential/account scope without persisting the credential
• keeps imported Platform tokens in memory and logs only opaque profile identifiers
• adds hard timeout behavior, profile-catalog preservation, and stable transition presentation

Reference: #1910

Privacy and reliability

• DeepSeek Platform tokens are never written to CodexBar config
• legacy DeepSeek cookieHeader values are removed during config normalization
• private Platform endpoints may change; parser failures degrade to balance-only data
• optional session resolution is cancellation-aware and hard-bounded

Validation

• swift test --filter DeepSeek — 91 tests passed
• swift test --filter ProviderSettingsDescriptorTests — 34 tests passed
• make check — passed with 0 lint violations
• git diff --check — passed

UI verification

Validated locally with multiple Chrome profiles:

• balance remains visible during profile changes
• the profile selector remains visible and shows Refreshing while disabled
• invalid/expired sessions are omitted
• detailed usage repopulates after the selected profile refresh completes

Screenshots

[clawsweeper]

Codex review: found issues before merge. Reviewed July 13, 2026, 8:14 PM ET / July 14, 2026, 00:14 UTC.

Summary
The PR adds optional DeepSeek Platform usage details, Chrome-profile session discovery and selection, credential-scoped profile persistence, stable refresh presentation, documentation, localization, and focused tests.

Reproducibility: not applicable. This PR adds an optional detailed-usage and browser-session workflow rather than repairing a defined failure of current behavior.

Review metrics: 3 noteworthy metrics.

• Change surface: 43 files, +3524/-116. The branch spans browser credential import, provider networking, persisted settings, presentation state, localization, documentation, and tests.
• New browser importer: 475 lines added. The central new credential-access component is substantial enough that its architectural boundary matters independently of green unit tests.
• Focused validation: 91 DeepSeek tests reported. The contributor supplied broad parser, timeout, profile-selection, migration, and presentation coverage, although the exact head still has failing macOS jobs.

Root-cause cluster
Relationship: canonical
Canonical: #2135
Summary: This PR is the active implementation candidate for improved DeepSeek Platform usage; the earlier closed branch overlaps substantially but is broader and is not a viable replacement.

Members:

• partial_overlap: Add DeepSeek platform session usage dashboard and status submenu #1910 - The closed unmerged PR also implemented DeepSeek Platform session usage, but added broader status and submenu behavior and cannot safely supersede this active branch.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

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

Rank-up moves:

• Obtain the browser-boundary decision and refactor discovery through the explicit host API if that recommended direction is confirmed.
• Remove the CHANGELOG.md edit and update the PR body so its legacy-session migration description matches the tested behavior.
• Restore green macOS checks on the exact head; updating the PR body or head should trigger a fresh review, otherwise a maintainer can comment @clawsweeper re-review.

Risk before merge

• [P1] Merging the direct Chrome local-storage importer would establish a new provider-specific credential and consent boundary outside the documented browser host API.
• [P1] The PR body says legacy cookieHeader values are removed, while the current code and tests deliberately preserve and project them; maintainers should confirm and document the intended upgrade behavior.
• [P1] The exact head still has failing macOS test jobs, so merge validation is incomplete even though focused tests and lint were reported locally.

Maintainer options:

1. Refactor session access before merge (recommended)
   Route DeepSeek discovery through the browser host API, preserve legacy upgrade behavior, remove the release-owned changelog edit, and rerun the failing checks.
2. Accept the new credential boundary
   A repository owner may intentionally approve direct Chrome inspection after confirming its consent, prompting, token-storage, and migration contract.
3. Pause automatic enrichment
   Keep the documented API-key balance path and defer automatic Platform enrichment if the browser boundary is not worth supporting.

Next step before merge

• The repository owner should first choose the Chrome session-discovery and consent boundary; after that decision, the contributor can perform the corresponding refactor, align the migration description, remove the changelog entry, and restore green checks.

Maintainer decision needed

• Question: Must DeepSeek Platform session discovery use the existing browser host API with explicit user initiation, or may this provider directly inspect Chrome local storage for live authentication tokens?
• Rationale: This choice establishes a repository-wide security, privacy, and consent precedent that cannot be resolved from implementation correctness or test coverage alone.
• Likely owner: steipete — As repository owner and owner of the documented provider boundary, steipete is the strongest available decision owner for this credential-access precedent.
• Options:
  • Use the browser host API (recommended): Refactor session discovery through the existing explicit host/import seam and keep it user-initiated while retaining balance-only fallback behavior.
  • Approve direct discovery: Explicitly accept provider-specific Chrome local-storage inspection after documenting consent, prompting, token lifetime, and upgrade behavior.
  • Defer browser enrichment: Pause or remove automatic session discovery until a repository-wide browser-session architecture is approved.

Security
Needs attention: The branch avoids persisting or logging imported tokens, but its direct Chrome local-storage discovery creates an unapproved credential-access and consent boundary.

Review findings

• [P1] Route Chrome discovery through the browser host API — Sources/CodexBarCore/Providers/DeepSeek/DeepSeekPlatformTokenImporter.swift:62
• [P3] Remove the release-owned changelog entry — CHANGELOG.md:13-15

Review details

Best possible solution:

Keep API-key balance authoritative and independently available, but implement optional Platform enrichment through an explicit user-initiated browser host API that centralizes consent and token handling, preserves compatible legacy sessions, scopes profile choices to the active account, and degrades safely to balance-only data.

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

Not applicable: this PR adds an optional detailed-usage and browser-session workflow rather than repairing a defined failure of current behavior.

Is this the best way to solve the issue?

No. The optional-enrichment and fallback design is reasonable, but provider-specific direct Chrome inspection is not the narrowest maintainable solution; browser access should use the repository’s centralized, explicit host API unless the owner intentionally changes that policy.

Full review comments:

• [P1] Route Chrome discovery through the browser host API — Sources/CodexBarCore/Providers/DeepSeek/DeepSeekPlatformTokenImporter.swift:62
  This prior blocker remains unresolved on the unchanged reviewed head. The provider now performs its own Chrome local-storage session discovery to obtain live authentication tokens, despite the provider guide requiring browser internals to stay behind explicit host APIs. Refactor this path through the user-initiated browser host/import seam, or obtain an explicit repository-owner decision approving the new boundary.
  Confidence: 0.97
• [P3] Remove the release-owned changelog entry — CHANGELOG.md:13-15
  Remove this entry from the feature branch because CHANGELOG.md is maintained by the release process. Late discovery: the current head is identical to the prior reviewed SHA, so this policy violation was equally visible in the earlier review cycle.
  Confidence: 0.99
  Late finding: first raised on code an earlier review cycle already covered.

Overall correctness: patch is incorrect
Overall confidence: 0.96

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 315ff65f7b2a.

Label changes

Label justifications:

• P2: This is a substantial optional provider improvement with limited blast radius, not an urgent regression or unusable core workflow.
• merge-risk: 🚨 compatibility: The PR changes persisted DeepSeek profile configuration and legacy browser-session migration behavior, with the PR description contradicting the tested migration path.
• merge-risk: 🚨 auth-provider: The PR associates imported browser sessions and profile selections with API credentials and saved account slots, so a scoping error could display data from the wrong DeepSeek account.
• merge-risk: 🚨 security-boundary: The PR directly discovers live Chrome authentication tokens and sends them to private DeepSeek Platform endpoints outside the documented provider host boundary.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (screenshot): The screenshots and described multi-profile local run show the changed settings and usage flow working after the fix, including balance preservation, refresh presentation, invalid-session filtering, and usage repopulation; any additional diagnostics should remain redacted.
• proof: sufficient: Contributor real behavior proof is sufficient. The screenshots and described multi-profile local run show the changed settings and usage flow working after the fix, including balance preservation, refresh presentation, invalid-session filtering, and usage repopulation; any additional diagnostics should remain redacted.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The screenshots and described multi-profile local run show the changed settings and usage flow working after the fix, including balance preservation, refresh presentation, invalid-session filtering, and usage repopulation; any additional diagnostics should remain redacted.

Evidence reviewed

Security concerns:

• [medium] Centralize live browser-token access — Sources/CodexBarCore/Providers/DeepSeek/DeepSeekPlatformTokenImporter.swift:62
  Provider-specific code discovers live DeepSeek authentication state directly from Chrome local storage; route this through the repository browser host API so prompting, explicit consent, credential handling, and future browser support remain centralized.
  Confidence: 0.97

What I checked:

• Prior blocker remains on the current head: The current head is still fc76f8a, exactly the SHA reviewed in the previous cycle that raised “Route Chrome session discovery through the browser host API”; no later commit can have resolved that finding. (Sources/CodexBarCore/Providers/DeepSeek/DeepSeekPlatformTokenImporter.swift:62, fc76f8ae6a51)
• Repository provider boundary: The current provider guide requires provider implementations to use explicit host APIs and states that providers must not read browser internals directly; it also requires sensitive browser access to remain user-initiated and opt-in. (docs/provider.md:300, 315ff65f7b2a)
• Direct browser-session importer: The branch adds a 475-line provider-specific importer that discovers DeepSeek tokens from Chrome local storage, validates profiles, and passes live authentication tokens to private Platform endpoints rather than routing discovery through the documented host boundary. (Sources/CodexBarCore/Providers/DeepSeek/DeepSeekPlatformTokenImporter.swift:62, fc76f8ae6a51)
• Legacy upgrade coverage: The revised branch preserves a legacy DeepSeek browser token and canonicalizes existing profile paths, resolving the earlier migration finding, although this now contradicts the PR body’s statement that legacy cookieHeader values are removed. (Tests/CodexBarTests/ProviderConfigEnvironmentTests.swift:606, fc76f8ae6a51)
• After-fix behavior proof: The PR body provides screenshots and reports a real multi-profile run in which balance remains visible, invalid sessions are omitted, the selector shows its refresh transition, and detailed usage repopulates after selection. (fc76f8ae6a51)
• Existing DeepSeek usage ownership: Merged release history credits Yuxin-Qiao with the existing optional DeepSeek web-session usage and cost summaries, making that work the closest current-main feature ancestry for this extension. (Sources/CodexBarCore/Providers/DeepSeek/DeepSeekUsageFetcher.swift:29, 7ba98d4)

Likely related people:

• steipete: The unresolved question concerns the repository-wide provider host API, browser credential access, and consent boundary documented on current main. (role: repository owner and architecture decision owner; confidence: high; commits: 315ff65f7b2a; files: docs/provider.md, Sources/CodexBarCore/ProviderSupport/BrowserSessionHost.swift)
• Yuxin-Qiao: Merged release history attributes the existing DeepSeek optional web-session usage summaries to this contributor, and they also authored the closely overlapping earlier implementation. (role: DeepSeek web-session feature contributor; confidence: high; files: Sources/CodexBarCore/Providers/DeepSeek/DeepSeekUsageFetcher.swift, Sources/CodexBarCore/UsageFetcher.swift, Sources/CodexBar/InlineUsageDashboardContent.swift)
• giuseppebisemi: Earlier merged DeepSeek balance work and recent provider-guide history connect this contributor to both the current provider behavior and its supported extension pattern. (role: DeepSeek balance and provider architecture contributor; confidence: medium; files: Sources/CodexBarCore/Providers/DeepSeek/DeepSeekUsageFetcher.swift, docs/provider.md)
• willytop8: Release history credits this contributor with introducing the original DeepSeek provider and token-account balance tracking. (role: original DeepSeek provider contributor; confidence: medium; files: Sources/CodexBarCore/Providers/DeepSeek/DeepSeekProviderDescriptor.swift, Sources/CodexBarCore/Providers/DeepSeek/DeepSeekSettingsReader.swift)

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 (2 earlier review cycles)

• reviewed 2026-07-13T21:38:36.799Z sha 178b354 :: found issues before merge. :: [P1] Preserve legacy DeepSeek sessions during migration
• reviewed 2026-07-13T23:06:05.768Z sha fc76f8a :: found issues before merge. :: [P1] Route Chrome session discovery through the browser host API