fix(switch): stop the Codex CLI daemon when switching accounts

[fajarmf10]

Problem

After a switch, new Codex CLI sessions can keep using the previous account. ~/.codex/auth.json holds the new account, but the CLI does not read it.

Root cause

Codex CLI 0.160.0 runs interactive sessions on a shared app-server daemon (codex app-server --listen unix:// --managed-daemon) unless --no-daemon is passed. The daemon loads auth.json once, when it starts, and keeps those credentials in memory. The switcher only rewrites auth.json and counts every codex app-server process as a background process, so the daemon keeps serving the old account until it restarts.

Reproduced with a separate CODEX_HOME: the daemon still reported account A after auth.json changed to account B, and reported B only after a restart.

Fix

• On switch, after the running-Codex check and before auth.json changes, stop the managed daemon with $CODEX_HOME/packages/app-server-daemon/current/bin/codex app-server daemon stop. The next CLI session starts a new daemon, which loads the new account.
• The daemon is found through $CODEX_HOME/app-server-daemon/daemon.pid. The pid must belong to a process with app-server and --managed-daemon in its command line.
• check_codex_processes returns cli_daemon_running, and the header shows a "CLI daemon running" badge.
• A failed stop is logged and does not fail the switch.

Stop, not restart: a daemon that the switcher starts inherits the GUI app environment (on macOS a minimal PATH), which then reaches MCP servers and tools. A daemon that the CLI starts gets the terminal environment.

Limits: Unix only; on Windows the detection returns false. Stopping the daemon ends work that still runs on it, for example a headless codex exec or a remote-control session. Interactive CLI sessions already block the switch.

Testing

• cargo test (new unit tests for pid file parsing and command matching), pnpm build, pnpm test.
• macOS, Codex CLI 0.160.0: ran the stop path against a daemon in a separate CODEX_HOME. It found the daemon, stopped it, and then reported no daemon. A new CLI session started a fresh daemon.