MCP servers start before user config is loaded during /login, ignoring mcpServers settings

Description

When a Claude Code session requires re-authentication (/login), the chrome-devtools-mcp MCP server is launched before the user's .claude.json configuration is loaded. This means any args specified in the mcpServers config (such as --chromeArg=--disable-gpu) are not applied during the login flow.

Environment

• OS: WSL2 (Ubuntu 24.04) on Windows, GPU disabled at system level
• Chrome: 146.0.7680.177 (system install)
• Claude Code: latest
• MCP: chrome-devtools-mcp@latest

Config (working when logged in)

// ~/.claude.json → mcpServers
"chrome-devtools": {
  "type": "stdio",
  "command": "npx",
  "args": [
    "-y",
    "chrome-devtools-mcp@latest",
    "--chromeArg=--disable-gpu",
    "--chromeArg=--disable-software-rasterizer"
  ]
}

Steps to reproduce

1. Have a WSL2 system with GPU disabled
2. Configure chrome-devtools MCP with --disable-gpu flags in ~/.claude.json
3. Let the session expire / log out
4. Run /login — Claude Code launches Chrome via MCP to open the OAuth page
5. Chrome starts without --disable-gpu flags → attempts GPU rendering → freezes the entire WSL2 system

Expected behavior

MCP server arguments from ~/.claude.json should be applied even during the /login flow, or the login flow should not use MCP servers that depend on user configuration.

Additional context

• Puppeteer (used by chrome-devtools-mcp) launches Chrome directly (/opt/google/chrome/chrome), bypassing the system wrapper script that reads chrome-flags.conf — so system-level Chrome flag configs are also ignored.
• Workaround: replace /opt/google/chrome/chrome with a wrapper script that always injects --disable-gpu.