fix(cli): serialize object daemon arguments

[mcc0nnell]

Summary

Fix daemon argument serialization for object-valued CLI options.

serializeArgs() currently falls back to String(value) for non-boolean, non-array values. Yargs parses options such as wsHeaders into an object, so direct serialization produces [object Object] and the daemon cannot reconstruct the value.

This change serializes object values with JSON.stringify() while preserving the existing behavior for primitive, boolean, and array options.

Review follow-up

The earlier review also identified CLI-injected isolated / headless defaults interacting badly with --config. Current upstream main has since removed those assignments entirely, so after rebasing there is no additional default-guard change to carry in this PR.

Validation

• focused serializeArgs regression for object values
• git diff --check

[OrKoN]

let's fix the serilization issue without adding the env variable support. Could the --config option documented here https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/configuration.md be used instead (it will be included in the next release #2691)

[mcc0nnell]

Updated per your suggestion — --config is the transport now.

I rebased onto current main and removed the environment-variable support entirely. The revised path does two things:

• config-backed wsHeaders: keep --config in the daemon argv and omit the already-resolved header value, so the daemon rereads the config;
• explicit --wsHeaders: keep the existing command-line semantics and JSON-serialize the parsed object correctly, including when it overrides a config value.

I also narrowed the security claim to just avoiding an unnecessary copy of config-held credentials into the daemon process argv. No claim that the config file itself is a secret store.

npm run typecheck and the focused CLI/daemon tests pass, including the Authorization canary regression.

[OrKoN]

Let's make these changes:

• Serialize object values (such as wsHeaders) directly inside serializeArgs in src/daemon/utils.ts (typeof value === 'object' ? JSON.stringify(value) : String(value)) and remove serializeArgsForDaemon and hasExplicitWsHeaders. Because src/bin/chrome-devtools.ts does not register Yargs .config(), argv.wsHeaders is never populated from --config in the CLI process, making hasExplicitWsHeaders dead code while leaving serializeArgs broken ([object Object]) for direct callers.
• Guard the argv.isolated = true and argv.headless = true defaults in src/bin/chrome-devtools.ts (lines 142–158) with !argv.config. When chrome-devtools start --config=... is used without CLI browser flags, injecting --isolated and --headless into the daemon argv overrides config values (isolated: false, headless: false) and causes a fatal Yargs conflict (Arguments isolated and userDataDir/autoConnect are mutually exclusive) when the daemon loads the config file.

[mcc0nnell]

Updated per the second review: object serialization now lives directly in serializeArgs; serializeArgsForDaemon / hasExplicitWsHeaders are gone; and the CLI no longer injects isolated / headless defaults when --config is present. On butcher with Node 22.22.3, typecheck and the focused daemon/CLI tests pass, and git diff --check is clean.