How to Filter Cookies by Domain During Cookie-Sync: CLI Guide and Examples

Use the --domains flag followed by a comma-separated list of hostnames to restrict the cookie-sync skill to specific domains and their subdomains.

The cookie-sync skill in the browserbase/skills repository exports cookies from your local Chrome instance and injects them into a Browserbase persistent context. When you need to synchronize only cookies belonging to specific hostnames—such as github.com or api.example.com—domain filtering prevents unnecessary data transfer and ensures only relevant authentication tokens reach your cloud browser sessions.

How Domain Filtering Works

The filtering logic resides in the main script at skills/cookie-sync/scripts/cookie-sync.mjs. When you provide the --domains argument, the skill performs a three-step process: parsing the CLI input, filtering the exported cookies, and injecting the matched results.

CLI Argument Processing

The script reads the comma-separated string passed to --domains and stores it as an array of lower-cased hostnames in CLI.domains. If you pass --domains github.com,Google.COM, the script normalizes both entries to lowercase before processing.

The filterCookies Function

Around line 193 of cookie-sync.mjs, the filterCookies(cookies, domains) function implements the matching logic:

function filterCookies(cookies, domains) {
  if (domains.length === 0) return cookies;
  return cookies.filter(cookie => {
    const cookieDomain = cookie.domain.replace(/^\./, '').toLowerCase();
    return domains.some(d => cookieDomain === d || cookieDomain.endsWith('.' + d));
  });
}

Domain normalization removes any leading dot (e.g., .github.com becomes github.com) and converts the string to lowercase for case-insensitive comparison.

Matching rules allow a cookie to pass if its domain either exactly matches a requested domain or ends with .<requested-domain>. This means requesting github.com captures both github.com and api.github.com, but excludes mygithub.com.

Cookie Injection

After filtering, the remaining cookies are transformed via toCookieParams and injected into the Browserbase context using cloud.context.addCookies(). According to the SKILL.md documentation, this process maintains the full cookie attributes (secure flags, expiration dates, and paths) while restricting the scope to your specified domains.

Practical Examples

Sync Only Specific Domains

To synchronize cookies for github.com and google.com (including any subdomains):

node .claude/skills/cookie-sync/scripts/cookie-sync.mjs \
  --domains github.com,google.com

The script exports all local cookies, retains only those matching the specified domains (including subdomains like api.github.com), and creates a new Browserbase context containing only these filtered results.

Update Existing Context with Domain Filter

To re-sync cookies for an existing context while limiting to myapp.com:

node .claude/skills/cookie-sync/scripts/cookie-sync.mjs \
  --context ctx_abcdef123 \
  --domains myapp.com

This refreshes only the cookies belonging to myapp.com in the persistent context ctx_abcdef123, leaving other domain cookies untouched.

Combine with Stealth Mode and Proxies

Domain filtering works orthogonally with other cookie-sync features like stealth mode and residential proxies:

node .claude/skills/cookie-sync/scripts/cookie-sync.mjs \
  --domains myapp.com,static.myapp.com \
  --stealth \
  --proxy "San Francisco,CA,US"

The --domains filter applies before injection, ensuring your stealth-enabled session only carries the minimal cookie set required for your target sites.

Key Implementation Details

The cookie-sync skill relies on several source files documented in REFERENCE.md:

• skills/cookie-sync/scripts/cookie-sync.mjs: Contains the core implementation including CLI handling, local.context.cookies() extraction, the filterCookies helper, and cloud.context.addCookies() injection.

• skills/cookie-sync/SKILL.md: Describes the --domains feature and provides usage examples for domain-restricted synchronization.

• skills/cookie-sync/REFERENCE.md: Documents the underlying Stagehand connections and Chrome DevTools Protocol (CDP) calls used for cookie extraction and injection.

Summary

• Use --domains followed by comma-separated hostnames (e.g., --domains example.com,api.example.com) to filter cookies during sync operations.
• Matching is case-insensitive and automatically handles leading dots in cookie domain attributes.
• Subdomains are included automatically—a filter for github.com matches github.com, www.github.com, and api.github.com.
• Implementation location: The filtering logic lives in filterCookies() inside skills/cookie-sync/scripts/cookie-sync.mjs around line 193.
• Compatible with other flags: Domain filtering works alongside --context, --stealth, and --proxy options without interference.

Frequently Asked Questions

Does the domain filter support wildcard patterns?

No, the current implementation in cookie-sync.mjs does not support glob or regex wildcards. The filterCookies function uses exact string matching and subdomain suffix matching (endsWith('.' + d)). To capture multiple subdomains, specify the root domain (e.g., example.com covers api.example.com and www.example.com).

Can I filter cookies when updating an existing Browserbase context?

Yes. Domain filtering applies whether you are creating a new context or updating an existing one via the --context flag. The script calls local.context.cookies() to fetch your local cookies, applies the domain filter, then injects only the matched cookies into the specified cloud context.

How does the filter handle cookies set on parent domains?

Cookies set on parent domains (those starting with a dot, like .github.com) are normalized before comparison. The regex /^\./ removes the leading dot, so a cookie with domain .github.com matches the filter github.com and synchronizes correctly with its subdomains.

Is there a performance benefit to filtering cookies by domain?

Yes. By limiting synchronization to specific domains, you reduce the payload size transferred to Browserbase and minimize the cookie jar size in your persistent context. This leads to faster context initialization and reduces the risk of hitting storage limits in long-running automation sessions.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}