fix: retain normalized ZoomMate parent cookies - #2507
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a550713013
ℹ️ 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".
| if normalizedDomain == Self.sharedParentCookieDomain { | ||
| return normalizedHost.hasSuffix("." + normalizedDomain) |
There was a problem hiding this comment.
When a browser profile contains a host-only cookie set on zoom.us, this unconditional special case treats it as a parent-domain cookie and adds it to requests for both API subdomains, even though the browser would send it to neither. Because the import query deliberately includes zoom.us, such records can enter this path and may leak or duplicate cookie names across hosts; distinguish domain cookies using the original BrowserCookieRecord.domain before makeHTTPCookies erases that information rather than treating every bare zoom.us value as shared.
Useful? React with 👍 / 👎.
clawsweeper
Bot
added
rating: 🦪 silver shellfish
|
Codex review: needs maintainer review before merge. Reviewed July 31, 2026, 7:02 PM ET / 23:02 UTC. ClawSweeper reviewWhat this changesThe PR restores Chromium’s domain-versus-host-only cookie scope before ZoomMate builds headers for its two approved API hosts, so normalized shared Merge readinessThis PR is still necessary: current Priority: P1 Review scores
Verification
How this fits togetherCodexBar reads cookies from a user-selected browser profile for enabled providers, then creates request headers for that provider’s fixed endpoints. ZoomMate uses the resulting per-host headers to bootstrap a session and fetch usage and credits. flowchart LR
Browser[Chrome Cookies database] --> Snapshot[Copied cookie snapshot]
Snapshot --> Records[Decrypted cookie records]
Snapshot --> Metadata[Chromium scope metadata]
Records --> Resolver[Fail-closed scope resolver]
Metadata --> Resolver
Resolver --> Headers[Approved-host cookie headers]
Headers --> ZoomMate[ZoomMate login and usage requests]
Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Merge the focused scope-recovery fix after maintainer review, preserving the two-host allowlist and the fail-closed treatment of uncertain Chromium cookie metadata. Do we have a high-confidence way to reproduce the issue? Yes. Current main’s normalized bare-domain handling is visible in the importer, and the contributor supplies a signed-in Chrome before/after packaged-CLI reproduction; this read-only review did not access any real browser cookie store. Is this the best way to solve the issue? Yes. Recovering Chromium’s original scope metadata before the existing fixed-host header filter is the narrowest safe repair; treating every normalized AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 8ef86077e70a. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (4 earlier review cycles)
|
Live verification for
|
| Chromium storage scope | ai.zoom.us |
zoommate.zoom.us |
|---|---|---|
.zoom.us domain cookie |
sent | sent |
host-only zoom.us cookie |
DomainMismatch |
DomainMismatch |
.ai.zoom.us domain cookie |
sent | DomainMismatch |
host-only ai.zoom.us cookie |
sent | DomainMismatch |
A controlled replay to the login endpoint also showed that the .zoom.us
parent-domain group returned a NAK, while the AI-leaf group alone did not. This
confirms that the parent-domain cookies are material to the login bootstrap.
SweetCookieKit normalizes both .zoom.us and host-only zoom.us to zoom.us,
so the normalized domain cannot reproduce Chrome's routing by itself. This
revision reads the non-secret Chromium scope metadata from the same copied
database snapshot used for decryption, joins it to the decrypted records by
domain/name/path, and then applies RFC 6265 matching:
- host-only cookies require an exact host match;
- domain cookies allow the exact domain or a dot-boundary suffix;
- missing, ambiguous, or partitioned scope metadata fails closed;
- the final headers remain restricted to the two fixed ZoomMate request hosts.
Automated verification
The focused suite passes:
$ swift test --filter ZoomMateCookieScopeTests
3 tests passed
It covers parent-domain routing, host-only and leaf isolation, dot-boundary
matching, hostile suffix rejection, root-path enforcement, and fail-closed
handling for missing/ambiguous/partitioned metadata.
Current PR checks:
- macOS test shard 0 — passed
- macOS test shard 1 — passed
- lint — passed
- Linux x64 — passed
- Linux musl — passed
- GitGuardian — passed
The remaining Linux ARM64
failure
is in the unrelated CLICardsClaudeSwapTests fake-executable test
(NSCocoaErrorDomain error 256). The CLI release build succeeded on ARM64, and
the identical test passed on Linux x64. The implementation and focused tests in
this revision are macOS-gated.
Packaged live CLI verification
$ CodexBar.app/Contents/Helpers/CodexBarCLI usage \
--provider zoommate --source web --format jsonSanitized result:
exitCode: 0
provider: zoommate
source: web
loginMethod: Cookie
primary credits payload: present
The packaged bundle identified commit 4acee6b2, and
codesign --verify --deep --strict passed. This confirms that the revised
importer can read the live Chrome session, complete the ZoomMate login
bootstrap, and fetch current credits.
For redaction: this comment includes no account identifier, usage amount,
cookie name or value, cookie header, bearer/NAK value, authorization header,
response body, or credential. The underlying CDP capture retained only routing
metadata (including cookie names and scopes); it never emitted or saved cookie
values, token values, authorization headers, or response bodies.
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
proof: sufficient
|
Confirmed @weddle's diagnosis and followed the single cookie-access-path policy. The exact loss happens between SweetCookieKit's Chromium reader and ZoomMate's destination partitioning. Chromium stores the shared SSO cookies (including the SweetCookieKit 0.5.1 does not retain or expose this scope. Its schema-v24 work validates and strips the encrypted value's domain hash, but I opened steipete/SweetCookieKit#19 with the library-level fix. It adds explicit host-only/domain scope to normalized records, carries it through Safari, Chromium, and Gecko imports, and includes Chromium fixtures for Validation is green: SweetCookieKit focused tests, its full 69-test suite, strict lint, and autoreview; CodexBar What remains: merge and release SweetCookieKit (no tag/release was made here), bump CodexBar to that release, then update ZoomMate to use |
|
The library-path fix is up in #2627. It bumps SweetCookieKit to 0.5.2 and uses the preserved browser cookie scope so parent |
|
Fixed on main via the library path: SweetCookieKit 0.5.2 now preserves host-only vs domain scope on normalized records (SweetCookieKit#19), and #2627 bumps CodexBar and makes ZoomMate route by real scope — parent Your diagnosis was precisely right; the only change from this PR's approach is where the fix lives — scope belongs in the shared cookie library rather than a provider-local Chromium reader, so every cookie provider benefits. Changelog credits you. Closing in favor of the landed pair; ships in 0.47.1. Thanks @weddle! |
2 participants
Summary
Fixes a live ZoomMate regression introduced by the host-partitioned cookie routing added during review of #2344.
SweetCookieKit normalizes Chromium parent-domain
.zoom.uscookies tozoom.usbefore creatingHTTPCookievalues. The current partitioning logic interprets that bare value as host-only, dropping the shared Zoom SSO cookies for both approved API hosts and preventing any browser session from being imported.This patch:
zoom.usparent domain as valid for bothai.zoom.usandzoommate.zoom.us;Live reproduction
Using the same signed-in Chrome session:
979fd6c)No ZoomMate session is cached and no session cookies were imported from ChromeValidation
swift build -c debug --target CodexBarCorepasses.ClaudeCLIBackgroundAvailabilityTests(missingincludePrepaidBalanceargument).