CLI processes share the GUI's Chromium profile, so the GUI loses localStorage while openscreen mcp runs #1137

Summary

Every CLI-mode process (openscreen mcp, export, record, sources, ...) opens the same Chromium profile as the GUI app, because it keeps the default sessionData path, which is userData (%APPDATA%\openscreen on Windows). Chromium's profile resources are single-process: whichever process starts first holds them, and the other one silently falls back to in-memory storage or fails to create its caches.

electron/main.ts skips requestSingleInstanceLock() for CLI runs on the grounds that "they share nothing but the recordings directory". They also share the Chromium profile: the CLI creates hidden BrowserWindows (runner windows in electron/cli/cliMain.ts, the hidden video window in electron/mcp/hidden-video.ts) on session.defaultSession.

Evidence (Windows 11, CI build of release/v2.1.0 @ 9c55596)

• Restart Manager reported the holder of %APPDATA%\openscreen\Local Storage\leveldb\LOCK and 000003.log to be a long-running electron.exe <worktree> mcp process. The leveldb log had not been written since that process started, while the GUI app ran.
• Effect in the GUI: localStorage is in-memory only. The "Use your system language?" HUD prompt came back on every launch after "Keep current language" and a clean quit (3 times). Theme and the other localStorage preferences are lost the same way.
• The reverse also happens: a stdio Openscreen.exe mcp started while the GUI runs logs Unable to move the cache: Access denied (0x5) and Gpu Cache Creation failed.

Impact

An agent keeping openscreen mcp alive (the documented MCP setup) makes every GUI preference stored in localStorage non-persistent for as long as it runs. Nothing tells the user.

Expected

A CLI process uses the real userData for app data (projects, recordings, settings, models) but its own Chromium session storage, so it never takes the GUI's profile, and concurrent CLI processes do not fight each other either.