Add ZoomMate usage provider

[weddle]

Closes #1997.

I work at Zoom; this is a personal contribution, not an official Zoom-sponsored or supported
integration. ZoomMate is Zoom's customer-facing AI agent product, not an internal Zoom tool. I am
happy to maintain this provider personally as its web-client endpoints evolve.

Summary

• Add an opt-in ZoomMate provider for pooled credit usage, reset timing, service status, and 30-day
  credit history/pacing.
• Support automatic Chrome session import and a manual cURL-capture mode. The cookie-to-short-lived-
  bearer exchange follows the accepted Factory/WorkOS provider shape discussed in Provider proposal: ZoomMate credit tracking — worth a PR? #1997.
• Store only a validated cookie header through CodexBar's existing Keychain-backed
  CookieHeaderCache; keep the minted bearer JWT in process memory only, bounded by its expiry.
• Restrict requests and manual captures to fixed HTTPS endpoints on ai.zoom.us and
  zoommate.zoom.us, with one-host failover only for non-auth/non-parse failures.
• Reuse shared provider UI and parser infrastructure. No new dependencies and no functional widget
  support are included.

Maintainer review bar

• Official Zoom domains only: request construction uses the fixed two-host allowlist;
  synthetic tests reject HTTP, lookalike domains, unrelated Zoom subdomains, ports, and wrong paths.
• No token logging: error logs contain operation/status only; marker tests verify cookie,
  bearer, and nak values never appear.
• Honest missing-cookie states: automatic, manual, and rejected-session paths surface distinct
  noSession, noCapture, and invalidCredentials recovery messages.
• Synthetic-payload tests: all ZoomMate fixtures, identities, credentials, credit values, and
  timestamps are synthetic; tests use transports/browser records/test cache stores only.
• Redacted live capture: included below from the bundled CLI built from this commit.

Redacted live proof

Bundled CLI succeeds from the persisted session with CodexBar closed

Run on July 19, 2026 against a live ZoomMate account using the locally packaged app from commit
33548f06. The app was closed before this command, demonstrating the prompt-free app-to-CLI cookie
cache handoff. The command projected only non-sensitive shape fields:

$ ./CodexBar.app/Contents/Helpers/CodexBarCLI usage \
    --provider zoommate --format json --pretty \
  | jq 'map({provider, source, succeeded:(.error == null), hasPrimary:(.usage.primary != null)})'
[
  {
    "provider": "zoommate",
    "source": "web",
    "succeeded": true,
    "hasPrimary": true
  }
]

The published projection contains no cookie, Authorization, bearer/nak, email, account or tenant
identifier, request identifier, credit value, or reset timestamp. No raw capture is committed.

Validation

• make check passes: SwiftFormat 0/1592 files, SwiftLint strict 0 violations/1591 files, plus locale,
  documentation-link, parser-hash, and site checks.
• 139 focused tests across seven ZoomMate/shared suites pass with Keychain access suppressed.
• ./Scripts/package_app.sh debug succeeds; the packaged CLI live proof above succeeds with the app
  closed.
• The full 723-selection local make test run stopped at the unchanged upstream timing assertion in
  KimiProviderTests.swift:751 (elapsed < 250ms). Four isolated reruns of that exact test produced
  two passes and two failures, confirming it is load-sensitive; this PR changes no Kimi files. GitHub
  Actions remains the authoritative full-suite and Linux check.

Scope notes

• ZoomMate is disabled until the user enables it and authenticates.
• Parent zoom.us access is cookie discovery only because the required SSO cookies are parent-scoped;
  RFC 6265 send-time narrowing drops cookies for unrelated sibling hosts.
• Functional widget support is intentionally out of scope. The widget switch arms are compile-time
  exhaustiveness stubs only.
• Zoom brand-color provenance is documented from Zoom's official brand portal in docs/zoommate.md.

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: Add ZoomMate usage provider This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 33548f065a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Continue past invalid Zoom cookie profiles

When Chrome has multiple profiles or cookie stores, this returns the first source that has any sendable zoom.us cookies. Since the query includes the broad parent domain, a profile with ordinary Zoom web cookies but no ZoomMate session can be chosen before a later profile that is actually signed in; the subsequent mint fails and the retry performs the same import again, so auto mode reports invalid/no session even though valid cookies exist. Validate each candidate before returning it, or continue to the next source when token minting rejects the cookies.

Useful? React with 👍 / 👎.

[weddle]

Good catch. Fixed in eb218d4. Automatic import now enumerates eligible Chrome cookie profiles and validates them in order. A bootstrap 401/403 advances to the next profile; network and parse failures still surface immediately, and only the first successfully validated session is persisted. Added regression coverage for both the rejected-first-profile success path and the non-fallback parse-failure path.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 19, 2026, 1:39 PM ET / 17:39 UTC.

Summary
The PR adds an opt-in ZoomMate usage provider with Chrome-cookie or manual cURL authentication, credit/status/history display, documentation, and focused tests.

Reproducibility: not applicable. as a feature request. The contributor provides a redacted live bundled-CLI result for the central credits fetch, while the rejected-profile follow-up is covered by focused regression tests.

Review metrics: 2 noteworthy metrics.

• Provider surface: 45 files affected; 3,945 added, 171 removed. This is a full provider integration spanning app, core, CLI, widget exhaustiveness, docs, and regression coverage rather than a narrow parser tweak.
• Authentication paths: 2 supported paths. Chrome cookie import and manual cURL capture both feed an auth-sensitive provider boundary that needs deliberate acceptance.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #1997
Summary: This PR is the implementation candidate for the open product-scope proposal; the proposal should remain open until a maintainer sponsors and merges or declines this implementation.

Members:

• canonical: Provider proposal: ZoomMate credit tracking — worth a PR? #1997 - The PR body uses closing syntax for this open proposal, whose central question is whether ZoomMate belongs in the provider catalog.

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

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

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

Rank-up moves:

• Obtain an explicit product/security decision on accepting ZoomMate and the opt-in browser-session flow.

Risk before merge

• [P1] Merging creates a new opt-in browser-session integration that reads Zoom-related cookies and exchanges them for bearer credentials; existing users are not migrated, but the repository must intentionally accept that credential-handling boundary and the provider’s ongoing endpoint-maintenance burden.
• [P1] The PR adds a public provider identifier and 45-file surface area, so future endpoint or authentication changes could require coordinated app, CLI, documentation, and test maintenance.

Maintainer options:

1. Approve the explicit session boundary (recommended)
   Merge only if the product owner accepts Chrome session-cookie discovery and first-party cookie-to-bearer exchange as an opt-in provider contract.
2. Pause pending scope policy
   Keep the branch out of the merge queue if CodexBar should not add this enterprise-provider or browser-session support surface.

Next step before merge

• [P2] A human owner must decide whether ZoomMate and its opt-in browser-session credential flow belong in the supported provider catalog before any merge action.

Maintainer decision needed

• Question: Should CodexBar accept ZoomMate as a supported provider and endorse this opt-in browser-cookie-to-short-lived-bearer authentication boundary?
• Rationale: The implementation can be reviewed mechanically, but only repository product ownership can decide whether an enterprise AI-agent credit product and its session-credential support burden fit the provider catalog.
• Likely owner: steipete — This is a provider-catalog and credential-boundary decision for the repository owner.
• Options:
  • Sponsor the opt-in provider boundary (recommended): Accept ZoomMate as a supported provider with Chrome-only import, fixed Zoom hosts, and in-memory bearer reuse as implemented.
  • Pause the integration: Decline or defer the provider until the product catalog or credential-boundary policy explicitly covers ZoomMate.

Security
Needs attention: No concrete credential leak or untrusted-host defect is established in the reviewed diff, but the new browser-cookie and bearer-token flow requires explicit owner approval of the security boundary.

Review details

Best possible solution:

If the product owner sponsors ZoomMate as a CodexBar provider, merge the opt-in Chrome-only implementation with its fixed-host, memory-only bearer boundary; otherwise pause or close the PR and keep the linked proposal as the scope decision record.

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

Not applicable as a feature request. The contributor provides a redacted live bundled-CLI result for the central credits fetch, while the rejected-profile follow-up is covered by focused regression tests.

Is this the best way to solve the issue?

Unclear pending product approval: the implementation reuses existing cookie-provider and Keychain-cache patterns, but accepting ZoomMate and its browser-session boundary is a repository-level policy choice.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add merge-risk: 🚨 security-boundary: The new provider reads browser-session cookies and exchanges them for a bearer token, even though it is opt-in and constrained to fixed first-party hosts.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• remove rating: 🦐 gold shrimp: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.

Label justifications:

• P2: This is a bounded but substantial provider addition awaiting a product and credential-boundary decision.
• merge-risk: 🚨 security-boundary: The new provider reads browser-session cookies and exchanges them for a bearer token, even though it is opt-in and constrained to fixed first-party hosts.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body includes a redacted terminal result from the packaged CLI against a live ZoomMate account, showing a successful provider result with CodexBar closed; the later profile-fallback change is additionally covered by focused regression tests.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes a redacted terminal result from the packaged CLI against a live ZoomMate account, showing a successful provider result with CodexBar closed; the later profile-fallback change is additionally covered by focused regression tests.

Evidence reviewed

Security concerns:

• [medium] Review the Zoom browser-session boundary — Sources/CodexBarCore/Providers/ZoomMate/ZoomMateCookieImporter.swift:16
  The provider reads Zoom-related browser cookies and uses them to obtain a bearer credential for ZoomMate APIs. The fixed-host and in-memory-token controls reduce exposure, but accepting this new opt-in credential path is a product/security decision before merge.
  Confidence: 0.91

What I checked:

• Provider implementation: The branch registers a new .zoommate provider and its descriptor declares it disabled by default, using Chrome-only browser-cookie import and shared provider infrastructure. (Sources/CodexBarCore/Providers/ZoomMate/ZoomMateProviderDescriptor.swift:10, 979fd6c4036e)
• Sensitive session boundary: The new importer reads Zoom-related browser cookies, including the parent domain for discovery, then narrows what can be sent to the two ZoomMate API hosts; this is intentionally security-sensitive even though the PR supplies host/path tests. (Sources/CodexBarCore/Providers/ZoomMate/ZoomMateCookieImporter.swift:16, 979fd6c4036e)
• Repository policy fit: The PR follows the applicable repository guidance by using Chrome-only cookie import where possible, keeping the bearer token in memory, and removing the release-owned CHANGELOG.md edit raised in the prior review cycle. (AGENTS.md:5, f8636cb37eb0)
• Canonical product discussion: The linked proposal remains open and explicitly asks whether ZoomMate, an enterprise AI agent rather than a strictly coding provider, belongs in CodexBar; it carries product-decision and security-review signals.
• Prior finding resolved: The current branch no longer changes CHANGELOG.md; the contributor’s follow-up states the release-owned entry was removed and the rebase added regression coverage for rejected-first-profile cookie import. (CHANGELOG.md:1, 979fd6c4036e)

Likely related people:

• steipete: The repository is owned by steipete, and the linked proposal identifies Peter’s prior scope invitation as the basis for this provider design; the remaining question is product acceptance rather than a narrow code repair. (role: likely product-direction owner; confidence: medium; files: Sources/CodexBarCore/Providers/ZoomMate/ZoomMateProviderDescriptor.swift, Sources/CodexBarCore/Providers/ZoomMate/ZoomMateCookieImporter.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 (1 earlier review cycle)

• reviewed 2026-07-19T17:22:28.997Z sha eb218d4 :: found issues before merge. :: [P3] Remove the release-owned changelog entry

[weddle]

Thanks for the review. I removed the release-owned CHANGELOG.md entry and rebased onto current upstream/main at ac9ed4c2 (new head 979fd6c4). make check is clean, and 141 focused tests across seven ZoomMate/shared suites pass with Keychain access disabled.

On product scope and the browser-session boundary, this PR follows Peter's explicit invitation in #1997, where the ZoomMate product fit and Factory/WorkOS-style cookie-to-short-lived-bearer shape were accepted. The provider remains opt-in and disabled by default.

Ready for maintainer review.