fix(cli): prevent env-derived flags from triggering implicit re-launch

[xiaodankasi]

Problem

When AGENT_BROWSER_EXECUTABLE_PATH (or other launch-related env vars / config values) is set, every CLI invocation that hits the daemon sends an implicit launch command — even when the user only runs a read-only action like get url.

Because this second launch omits flags the original launch included (e.g. --proxy), the computed launch_hash differs from the running browser's hash, causing the daemon to kill and re-launch the browser. The new browser instance starts at about:blank, breaking subsequent commands.

This was introduced in PR #996 (commit 05d86fa, shipped in v0.24.1) which added hash-based relaunch detection.

Root Cause

The launch condition in main.rs checks flags.executable_path.is_some() (among others), which is true whenever the env var AGENT_BROWSER_EXECUTABLE_PATH is set — regardless of whether the user explicitly passed --executable-path on the CLI. This means an env-only configuration silently triggers a launch command on every invocation.

Fix

Guard the implicit launch with has_explicit_launch_flags — a boolean that is true only when the user passes launch-relevant flags directly on the CLI (using the cli_* tracking fields introduced in PR #996 itself). When the daemon is already running and no explicit CLI launch flags are present, the launch command is skipped entirely.

This preserves PR #996's design intent: users can still explicitly change browser options mid-session with --headed, --proxy, etc., triggering a hash-aware relaunch. But env/config-derived values alone will no longer cause unintended relaunches.

Reproduction

# On a machine with AGENT_BROWSER_EXECUTABLE_PATH set:
agent-browser open --proxy http://proxy:port --session test
agent-browser --session test get url   # ← triggers relaunch, returns about:blank

Testing

Verified on Linux (Alibaba Linux, Chrome 140) where AGENT_BROWSER_EXECUTABLE_PATH=/usr/bin/google-chrome-140:

• open --proxy → get url (no explicit flags): browser stays alive, returns correct URL ✓
• open --proxy → get url --proxy (explicit flag): correctly triggers relaunch ✓
• open --headed → get url: no spurious relaunch ✓
• Fresh start (no daemon): launch proceeds normally ✓

Closes #1299

[vercel]

Someone is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[xiaodankasi]

Hi @ctate, could you take a look when you have a moment? This fixes a bug where env-derived flags (e.g. AGENT_BROWSER_EXECUTABLE_PATH) trigger an implicit re-launch on every CLI invocation, causing hash mismatches that kill the running browser. It also closes #1299. Thanks!

[vercel]

Missing cli_color_scheme and cli_engine tracking fields cause --color-scheme and --engine CLI flags to be silently ignored when daemon is already running.

[xiaodankasi]

Re: Vercel bot comment about missing cli_color_scheme and cli_engine —

These cli_* tracking fields do not exist in the codebase. flags.rs only defines: cli_headed, cli_executable_path, cli_profile, cli_state, cli_proxy, cli_args, cli_user_agent, cli_allow_file_access, cli_extensions, cli_download_path, and cli_hide_scrollbars.

Adding cli_color_scheme / cli_engine would be a separate enhancement. Also worth noting: color_scheme is not included in launch_hash(), so it does not affect relaunch behavior regardless.