Session cookies not persisting for specific subdomain pattern (dev.app.example.com)

[pfergi42]

Bug Description

The Chrome DevTools MCP browser fails to persist session cookies for a subdomain with the pattern dev.app.example.com, while identical server configurations work correctly for app.example.com (production) and localhost:3000 (local).

Environment

• chrome-devtools-mcp version: 0.8.1
• Platform: macOS (Darwin 25.0.0)
• Node version: v22.16.0
• Browser: Chrome DevTools MCP embedded browser

Steps to Reproduce

1. Navigate to https://dev.app.example.com/auth
2. Fill in login form with credentials
3. Submit login (POST /api/login)
4. Observe subsequent API requests fail with 401 Unauthorized

Expected Behavior

After successful login (POST /api/login returns 200), session cookie should be stored and sent with subsequent requests, allowing authenticated API calls to succeed.

Actual Behavior

• Login POST succeeds (200 OK)
• Session cookie is set in response: set-cookie: connect.sid=...; Domain=.example.com; Path=/; Expires=...; HttpOnly; Secure; SameSite=Lax
• Subsequent API requests (GET /api/user, etc.) fail with 401 Unauthorized
• Cookie is NOT sent in request headers of subsequent requests

Evidence

Dev Server (FAILING)

Set-Cookie Response Header:

set-cookie: connect.sid=s%3A[session-id]; 
Domain=.example.com; Path=/; Expires=Sat, 18 Oct 2025 21:11:28 GMT; HttpOnly; Secure; SameSite=Lax

Subsequent Request (missing cookie):

GET /api/user HTTP/1.1
Host: dev.app.example.com
[NO COOKIE HEADER PRESENT]

Result: 401 Unauthorized

Production Server (WORKING)

Set-Cookie Response Header:

set-cookie: connect.sid=s%3A[session-id]; 
Domain=.example.com; Path=/; Expires=Sat, 18 Oct 2025 21:05:25 GMT; HttpOnly; Secure; SameSite=Lax

Subsequent Request (cookie present):

GET /api/user HTTP/1.1
Host: app.example.com
Cookie: connect.sid=s%3A[session-id]

Result: 200 OK (authenticated)

Local Server (WORKING)

Works perfectly on http://localhost:3000 with cookies (no domain specified, localhost default).

Verification

1. Server-side verification: Sessions ARE being created in the PostgreSQL database with correct cookie configuration
2. Regular browser test: Login works perfectly in a regular Chrome browser window on dev.app.example.com
3. MCP browser comparison: Same server configuration works on app.example.com in MCP browser but fails on dev.app.example.com

Comparison Table

Environment	Domain Pattern	MCP Browser	Regular Chrome
Local	localhost:3000	✅ Works	✅ Works
Dev	dev.app.example.com	❌ Fails	✅ Works
Production	app.example.com	✅ Works	✅ Works

Analysis

The issue appears to be specific to how the MCP embedded browser handles cookies for the dev.app subdomain pattern versus the app subdomain pattern, despite both using identical cookie configurations (.example.com domain with secure, httpOnly, and SameSite=Lax).

This suggests a potential bug in the cookie storage/retrieval logic for certain subdomain patterns within the MCP browser implementation. The pattern seems to be:

• app.example.com ✅ works
• dev.app.example.com ❌ fails
• Both use Domain=.example.com in the cookie

Workaround

Use a regular Chrome browser for testing the problematic subdomain, or test authentication flows on production/local environments where MCP browser works correctly.

Additional Context

• Server framework: Express.js with express-session
• Session store: PostgreSQL (connect-pg-simple)
• Both dev and production use nginx as reverse proxy
• trust proxy is enabled on the Express app for both environments
• Cookie configuration is identical between working and non-working environments

[pfergi42]

✅ Issue Resolved

This issue has been fixed in PR #422.

Root Cause

Chrome's ThirdPartyStoragePartitioning and PartitionedCookies features were interfering with secure domain cookies on multi-level subdomains. The browser was creating non-secure host-specific cookies that overrode the server's secure domain cookies.

Solution

Added Chrome launch flags to disable the problematic features:

'--disable-features=ThirdPartyStoragePartitioning,PartitionedCookies'

Verification

Tested on dev.app.fieldcommerce.ai with successful results:

• ✅ Session cookies now persist correctly
• ✅ /api/user returns 200 OK (previously 401)
• ✅ Authentication flow works end-to-end
• ✅ Dashboard loads successfully after login

The fix is non-breaking and restores correct cookie behavior for multi-level subdomain environments.

PR #422 is ready for review and merge.

[OrKoN]

I am not sure it solves the issue. These features are enabled by default in Chrome https://chromium-review.googlesource.com/c/chromium/src/+/4886387 and https://chromium-review.googlesource.com/c/chromium/src/+/4385140 and they should be affecting all Chrome versions. So if cookies are not set due to this features, it's likely that this is expected. Are you testing with the same Chrome version? Which Chrome version is it?

Could you please share a test app that demonstrates the problem?

[pfergi42]

@OrKoN Thank you for the feedback! You're absolutely right to question this. Let me provide more context and test results.

Testing Environment

Chrome Version: 141.0.7390.108 (latest stable)
Same Chrome version used for all tests below

Test Results Comparison

Using Official chrome-devtools-mcp (npx chrome-devtools-mcp@latest):

• ✅ http://localhost:3000 - Login works
• ✅ https://app.example.com - Login works (single-level subdomain)
• ❌ https://dev.app.example.com - Login FAILS (multi-level subdomain)

Using Patched Version (with --disable-features flags):

• ✅ http://localhost:3000 - Login works
• ✅ https://app.example.com - Login works
• ✅ https://dev.app.example.com - Login NOW works

The Specific Issue

Session cookies with these attributes don't work on multi-level subdomains:

• Domain=.example.com (should match ALL .example.com subdomains)
• Secure flag (HTTPS only)
• HttpOnly flag
• SameSite=Lax

Expected: Cookie sent to dev.app.example.com (matches .example.com domain)
Actual: Cookie NOT sent to dev.app.example.com with official chrome-devtools-mcp

Network Evidence (Official Version)

POST https://dev.app.example.com/api/login
  ← 200 OK
  ← Set-Cookie: connect.sid=xxx; Domain=.example.com; Secure; HttpOnly; SameSite=Lax

GET https://dev.app.example.com/api/user
  → Cookie: (none sent) ❌
  ← 401 Unauthorized

Why This Seems Like a Bug

You're correct that ThirdPartyStoragePartitioning and PartitionedCookies are enabled by default across all Chrome versions. However:

1. These are first-party cookies (same domain, not third-party)
2. Inconsistent behavior: Works on single-level (app.example.com) but not multi-level (dev.app.example.com)
3. Domain cookie not respected: Domain=.example.com should match both depths

This suggests the partitioning logic may be incorrectly treating multi-level subdomains differently.

Minimal Reproduction Case

I'll create a minimal test app to demonstrate this. Would you prefer:

1. Standalone Node.js/Express app with cookie setup?
2. Puppeteer test script showing the behavior?
3. Docker Compose setup with everything pre-configured?

Let me know your preference and I'll provide a complete reproduction case.

Questions

1. Is this the intended behavior (treating subdomain depth differently)?
2. Should first-party domain cookies work across all matching subdomain levels?
3. Is there a cookie configuration that works properly with these features enabled?

I want to ensure we're solving the root cause, not just working around a security feature. Your guidance would be invaluable!

[pfergi42]

Minimal Reproduction Case

I've created a minimal standalone test app: https://gist.github.com/pfergi42/28546e73309d77a8a050505a18948cb7

Quick Start:

# Clone the gist
gh gist clone 28546e73309d77a8a050505a18948cb7
cd 28546e73309d77a8a050505a18948cb7

npm install

# Add to /etc/hosts
echo "127.0.0.1 app.example.com dev.app.example.com" | sudo tee -a /etc/hosts

# Generate SSL cert (required for Secure cookies)
mkcert -install
mkcert app.example.com dev.app.example.com localhost 127.0.0.1

# Update server.js to use HTTPS (see README for instructions)

npm start

Test Results:

1. https://app.example.com:3000 → ✅ Login works, authentication works
2. https://dev.app.example.com:3000 → ❌ Login works, authentication fails

What's happening:

• Cookie is set correctly with Domain=.example.com; Secure; HttpOnly; SameSite=Lax
• Cookie visible in DevTools → Application → Cookies for both domains
• Chrome sends the cookie to app.example.com ✅
• Chrome does NOT send the cookie to dev.app.example.com ❌

This is a first-party cookie that should match all subdomains of .example.com, but Chrome's ThirdPartyStoragePartitioning and PartitionedCookies features seem to be treating multi-level subdomains differently.

[pfergi42]

I found that this problem is also solved by clearing the cache, and relaunching:

rm -rf ~/.cache/chrome-devtools-mcp/chrome-profile

Feel free to close this issue @OrKoN

🤦‍♂️