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

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