Persist CLI defaults for automatic daemon startup #2388

Is your feature request related to a problem? Please describe.

The experimental chrome-devtools CLI automatically starts its background daemon when the first tool command is invoked. However, the automatic startup path currently calls start([], sessionId), so it cannot reuse user-specific startup options.

For example, a user may always need:

chrome-devtools start --executablePath /usr/bin/chromium --headless=false

If the daemon is not running after a reboot, crash, or explicit stop, invoking a normal command such as chrome-devtools navigate_page --url https://example.com starts it with the built-in defaults instead. The user must remember to run start manually before every new daemon lifecycle, which defeats part of the automatic-start behavior.

The standalone CLI currently has no persistent configuration file or environment-based defaults for options such as executablePath, headless, userDataDir, or other supported start options.

Describe the solution you would like

Add persistent startup defaults for the standalone chrome-devtools CLI.

One possible design is an XDG-compatible configuration file:

$XDG_CONFIG_HOME/chrome-devtools/config.json

with ~/.config/chrome-devtools/config.json as the fallback location. For example:

{
  "executablePath": "/usr/bin/chromium",
  "headless": false
}

When a tool command automatically starts the daemon, these configured values should be passed to the existing startup path instead of using only an empty argument list.

Suggested precedence:

explicit command-line options > configuration file > built-in defaults

The same defaults could also apply to an explicit chrome-devtools start command when an option is omitted. Existing option parsing and validation should be reused, and chrome-devtools status should continue to show the effective daemon arguments.

An equivalent persistent mechanism would also solve the problem if a configuration file is not considered appropriate.

Describe alternatives you have considered

• Run chrome-devtools start ... manually before every daemon lifecycle. This is easy to forget and bypasses automatic startup
• Define a shell wrapper or function that checks status and conditionally runs start. This is shell-specific, duplicates daemon management logic, and is harder for agents and scripts to use consistently
• Run a user-level service that always keeps the daemon alive. This is platform-specific and adds lifecycle management outside the CLI
• Configure startup arguments in an MCP client. This configures an MCP server launched by that client, not the standalone chrome-devtools CLI daemon

Additional context

The current automatic-start implementation is here:

https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/src/bin/chrome-devtools.ts#L262-L267

Related but distinct issues include:

• Plugin mode: support --browserUrl via pluginConfigs #1232, which concerns passing options through a Claude Code plugin configuration
• CLI or chrome-devtools-cli support --autoConnect ? #1184, which added --autoConnect support to the CLI
• The DevTools MCP is hardcoded to look for Chrome in standard locations #889, which concerns discovering Chrome installed in non-standard locations

This request is specifically about persisting defaults for the standalone CLI automatic daemon startup path.