[katulevskiy]

stacked on #926 (mcp launch args) and #927 (slash latency). merge those first; until then this diff includes their commits. the chrome-only changes are the last two commits (feat: per-device Claude in Chrome setting… and settings: Claude in Chrome toggle…).

summary

claude code chats in zeron can't use the claude in chrome extension, even for users who enabled it by default in claude. this adds a per-device zeron setting, claude in chrome, that launches new claude code sessions with --chrome. it is togglable in settings and over the zeron mcp.

why it didn't work

zeron runs claude as claude --print --input-format stream-json …. in --print mode the cli ignores claudeInChromeDefaultEnabled from ~/.claude.json; the chrome tools only load when --chrome is passed explicitly. measured with claude 2.1.301:

args	claude-in-chrome server	chrome tools
zeron's current args	not loaded	0
+ --chrome	connected	22

what's added

• harness: ClaudeHarness::with_chrome_default(Arc<AtomicBool>). ordinary runs add --chrome while the flag is set. title runs and discovery probes never do. the flag is read at spawn, so a change applies to sessions started afterwards, and running sessions keep their setting.
• engine: harness-prefs.json gains claude.chrome.
  • import once: on first load it is imported once from claude's config ($CLAUDE_CONFIG_DIR/.claude.json, else ~/.claude.json, key claudeInChromeDefaultEnabled). a missing file, bad json or a missing key gives false. it is persisted right away, so later edits to claude's own config don't move it.
  • sharing: the registry owns the Arc<AtomicBool> and shares it with the claude factory.
• rpc: GetHarnessSettings → { claudeChrome } and SetHarnessSettings { claudeChrome } → { claudeChrome }. both are relay-forwardable with targetDeviceId, like the title settings.
• mcp: new set_harness_settings { device?, claude_chrome } tool, so agents can turn it on or off for a device. list_harnesses reports settings.claudeChrome, and omits it for older devices.
• ui: settings → providers → claude code panel has a "browser" section with a claude in chrome switch.
  • it targets the selected device and refetches on device switch.
  • writes are optimistic and revert with an error toast on failure.
  • the row is hidden on devices that don't answer GetHarnessSettings, i.e. older versions.

trade-offs

• this is off unless the user turned it on in claude or in zeron. with it on, every new claude session on that device shares one real chrome profile, signed in as the user. many parallel agents can contend for it, and auto-approve chats act on signed-in sites without prompting. that's why this is a visible per-device toggle rather than an unconditional --chrome.
• with mcp: launch args for agent chats #926, a single chat can override the device setting with args: ["--chrome"] / ["--no-chrome"]. the device --chrome goes before the chat's args, so a chat's --no-chrome wins (device_chrome_precedes_a_chat_no_chrome).

tests

• zeron-harness --test claude: 30 passed. --chrome is present only when the flag is set, and never for title runs or probes.
• zeron-harness --lib claude: 41 passed, including device_chrome_precedes_a_chat_no_chrome.
• zeron-engine --lib registry: 37 passed. import-once is covered for true, false, a missing file, bad json and a non-bool value, plus the source file changing afterwards, a persistence round-trip and the shared flag updating.
• zeron-engine --lib rpc: 26 passed.
• zeron-mcp: 36 passed, including harness_settings_round_trip_and_older_devices_omit_them.
• zeron-ui settings::harnesses: 9 passed, 5 of them new. they cover the loaded value, the flipped write, device targeting and refetch, revert on failure, and the hidden row on unsupported devices.
• cargo check --workspace --all-targets is clean on the stacked branch.