Provider proposal: ZoomMate credit tracking — worth a PR?

[weddle]

What: ZoomMate is an enterprise AI agent developed by Zoom that works on a credit-based model (a pooled monthly credit allotment, not a coding-tool subscription). This is a Zoom product offering to customers, not an internal tool. I've built a CodexBar provider that tracks the credit balance, 30-day credit history, and burn-rate pacing.

Fit: It follows the existing credit-based provider pattern (Poe, Abacus, Venice) and renders entirely through the shared inline-dashboard and descriptor
surfaces — no bespoke UI. Auth uses ZoomMate's own first-party web-client cookie→token flow, the same shape as the accepted Factory (WorkOS) provider; the minted token is cached in memory only and nothing is persisted to disk.

Status: Implemented and opt-in, narrow in scope, on a personal fork rebased onto current main, with tests and docs. Builds and runs today.

Disclosure: I work at Zoom and am happy to maintain this long-term.

Ask: Given this is an enterprise AI agent, not strictly coding, is it still a fit for CodexBar? Checking before opening the PR.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 8, 2026, 3:48 PM ET / 19:48 UTC.

Summary
Keep open: the new comment adds useful endpoint, token, cookie-scope, privacy, and redacted runtime context, but ZoomMate is still absent from current main and the latest release, so this remains a maintainer product/auth decision before a PR.

Reproducibility: not applicable. this is a provider proposal/product fit question, not a reported failing behavior. Current-main and latest-release searches found no ZoomMate provider to exercise.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
Manual review is needed because the blocker is provider scope plus auth/privacy approval, not a source-level bug suitable for an automated fix PR.

Maintainer decision needed

• Question: Should CodexBar accept a ZoomMate provider PR for an enterprise AI agent that is not strictly a coding tool but uses the existing credit-provider UI and first-party cookie-to-token auth pattern?
• Rationale: The proposal fits CodexBar's provider/credit surface in shape, but VISION.md and AGENTS.md make new provider scope plus auth/privacy behavior a maintainer sign-off decision before implementation work starts.
• Likely owner: steipete — This is primarily a core provider-scope and auth/privacy policy choice, and steipete owns the repository and the provider architecture direction in history.
• Options:
  • Invite a narrow PR (recommended): Ask the contributor to open the opt-in provider PR with descriptor/fetch-strategy wiring, docs, focused tests, cookie-domain narrowing, in-memory token handling, log redaction, and redacted runtime proof.
  • Request a short design note first: Ask for a concise endpoint/auth/privacy design if maintainers want to review the Zoom-specific cookie and token boundary before a full branch lands in review.
  • Decline core scope: Keep CodexBar focused on coding-provider surfaces and ask the contributor not to submit ZoomMate to core.

Security
Needs attention: No patch exists yet, but the proposed provider is auth/privacy-sensitive because it imports Zoom cookies and mints a bearer token.

Review details

Best possible solution:

If maintainers accept the scope, invite a narrow descriptor-driven ZoomMate PR with parser/fetcher tests, provider docs, explicit cookie-domain/token/privacy notes, and no bespoke UI.

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

Not applicable; this is a provider proposal/product fit question, not a reported failing behavior. Current-main and latest-release searches found no ZoomMate provider to exercise.

Is this the best way to solve the issue?

Unclear until maintainer confirms scope; if accepted, the reporter's descriptor-driven provider approach is the maintainable path because it matches the documented provider architecture and avoids bespoke UI.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Maintainers still need to decide whether a non-coding enterprise AI agent belongs in CodexBar core provider coverage.
• The proposed auth path reads parent-domain Zoom cookies and mints a bearer token, so domain narrowing, token lifetime, non-persistence, and redaction need maintainer review before inviting a PR.

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

Label changes

Label changes:

• add impact:security: The proposal handles browser cookies, minted bearer tokens, cache lifetime, and log redaction for sensitive auth data.
• add impact:auth-provider: The proposed work adds a new provider and first-party cookie-to-token auth flow.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P3: This is a speculative provider-scope proposal with no current broken user workflow or regression.
• impact:auth-provider: The proposed work adds a new provider and first-party cookie-to-token auth flow.
• impact:security: The proposal handles browser cookies, minted bearer tokens, cache lifetime, and log redaction for sensitive auth data.

Evidence reviewed

Security concerns:

• [medium] Review the Zoom cookie-to-token boundary
  Before accepting a PR, maintainers should verify that parent-domain Zoom cookies are narrowed exactly like a browser request, minted bearer tokens remain memory-only, sensitive values are redacted, and no extra browser prompts or persisted secrets are introduced.
  Confidence: 0.86

What I checked:

• Issue discussion: The reporter clarified first-party ZoomMate endpoints, one-hour in-memory bearer-token caching, Chromium-only cookie import with send-time domain narrowing, log redaction, and included a redacted screenshot of the fork running through standard credit-provider surfaces.
• Current main has no ZoomMate provider: A current-main source, test, doc, README, and package search for ZoomMate/Zoom endpoint identifiers returned no matches. (aa401f1d8b74)
• Latest release also has no ZoomMate provider: The same ZoomMate/Zoom endpoint search against v0.41.0 returned no matches, so this is not already shipped. (a83a83fa4131)
• Provider registry boundary: Current main uses exhaustive provider registration through UsageProvider, ProviderDescriptorRegistry, and ProviderImplementationRegistry, and ZoomMate is not in those registered provider lists. (Sources/CodexBarCore/Providers/ProviderDescriptor.swift:55, aa401f1d8b74)
• Provider authoring path: The provider guide says a new provider requires a UsageProvider case, descriptor/fetch strategy files, app implementation, registry wiring, icon/color, tests, and docs. (docs/provider.md:162, aa401f1d8b74)
• VISION fit and sign-off: VISION.md frames CodexBar around provider limits, credits, spend, status, and reset windows, but puts new features and provider auth/privacy behavior in the sign-off bucket. (VISION.md:1, aa401f1d8b74)

Likely related people:

• steipete: The provider registry, provider authoring guide, and product-scope VISION guidance trace to Peter Steinberger's provider architecture and release work, making this the best owner for the scope decision. (role: repository owner and provider architecture owner; confidence: high; commits: 70a02ebbdda5, 7fbfe0927abb, a83a83fa4131; files: Sources/CodexBarCore/Providers/ProviderDescriptor.swift, Sources/CodexBar/Providers/Shared/ProviderImplementationRegistry.swift, docs/provider.md)
• ratulsarna: Introduced the Abacus AI credit/cookie provider, one of the existing credit-provider patterns the proposal cites as precedent. (role: adjacent provider contributor; confidence: medium; commits: c56ee9b13ff4; files: Sources/CodexBarCore/Providers/Abacus/AbacusProviderDescriptor.swift, Sources/CodexBarCore/Providers/Abacus/AbacusUsageFetcher.swift, Sources/CodexBar/Providers/Abacus/AbacusProviderImplementation.swift)
• Yuxin Qiao: Introduced the Poe current-balance provider, another credit/balance provider pattern cited by the proposal. (role: adjacent provider contributor; confidence: medium; commits: 6d906d375d2e; files: Sources/CodexBarCore/Providers/Poe/PoeProviderDescriptor.swift, Sources/CodexBarCore/Providers/Poe/PoeUsageFetcher.swift, Tests/CodexBarTests/PoeUsageFetcherTests.swift)
• JoeVenner: Recently worked on WorkOS-related provider auth behavior, which is adjacent to the proposed first-party cookie-to-token flow. (role: recent adjacent auth contributor; confidence: low; commits: aa401f1d8b74, 30ae39a7ee83; files: Sources/CodexBarCore/Providers/Ollama/OllamaUsageFetcher.swift, Tests/CodexBarTests/OllamaUsageFetcherTests.swift, docs/ollama.md)

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.

[weddle]

Thanks for the fast triage — "invite a narrow PR" is what I'm aiming for: opt-in, descriptor-driven, tests + docs, no bespoke UI. Additional context that clawsweeper requested:

• Endpoints (all first-party — the same ones ZoomMate's own web client calls): a login cookie→bearer bootstrap on ai.zoom.us, then credits/status and credits/history.
• Token lifetime: the minted bearer is a ~1h JWT, held in an in-memory cache only (keyed by a SHA-256 of the cookie session), reused until exp − 60s, evicted on 401/403, and never written to disk.
• Cookie source: Chromium-only import, in line with CodexBar's Chrome-only-by-default cookie policy. Zoom's SSO cookies are parent-zoom.us-scoped, so the import reads them but narrows the set at send time (RFC 6265) to only what a browser would send to ai.zoom.us/zoommate.zoom.us, dropping unrelated *.zoom.us siblings.
• Privacy: nothing persisted beyond the existing browser session; logs omit cookies, tokens, nak, and response bodies.

The cookie→token shape mirrors the accepted Factory (WorkOS) provider. It's on a personal fork rebased onto current main, with parser/fetcher tests and docs/zoommate.md. Happy to open the narrow PR on a green light (from my fork, with "Allow edits by maintainers" on).

Here's it running (redacted):
ZoomMate credits, 30-day history, and pace, all through the standard credit-provider surfaces:

[steipete]

Feasibility research update: legitimate product, viable shape, PR invited.

ZoomMate is a real Zoom product (launched June 2026, $20/user/month with pooled monthly AI credits), so credit tracking is a genuine need. There's no public API; the workable shape is first-party web endpoints on ai.zoom.us bootstrapped from a zoom.us login cookie into a short-lived bearer, which matches the accepted Factory/WorkOS provider pattern. You mentioned a working fork with tests, docs, in-memory-only tokens, and RFC 6265 cookie narrowing: please open that as a PR. Review bar: official Zoom domains only, no token logging, honest states when the cookie is missing, synthetic-payload tests, plus a redacted live capture.

[weddle]

Thanks, Peter. I opened PR #2344

It addresses the requested review bar directly: fixed official Zoom hosts, no token or response-body logging, honest missing/rejected-session states, synthetic payload tests, and a redacted live CLI capture. Maintainer edits are enabled.

One implementation detail evolved from my earlier issue comment: after validation, the narrowed cookie header is cached using CodexBar’s existing Keychain-backed CookieHeaderCache, allowing background refreshes and the bundled CLI to work without rereading Chrome. The short-lived bearer remains memory-only and is never logged or persisted.

This remains a personal contribution rather than an official Zoom-supported integration, and I’m happy to maintain it.