Function isolated_muxbus_reconnect_enabled 

pub fn isolated_muxbus_reconnect_enabled() -> bool

Skip the automatic, EAGER MuxBus cloud-session reconnect (CloudSubscriber::init_global, called at boot) on a randomized per-build local-package channel. See docs/retro/retro-macos-0560-stale-cef-cache-launch-crash-2026-09-16.md for the incident this closes.

Without this flag, CloudSubscriber::init_global (crates/srv/src/bootstrap/background.rs) runs on every launch (unless AGENTMUX_DISABLE_CLOUD_SUBSCRIBER is set) and performs a real, synchronous OS-keychain read of the single global muxbus:global credential almost immediately. On macOS that read requires interactive OS consent the first time a given code signature touches it — and every local task package:macos/task package/task package:linux build bakes a brand-new, randomized per-build channel (and, on macOS, a bundle identifier derived from it) into the binary. So every fresh local build looks like a never-before-seen app to the Keychain, and the same already-Always Allow’d credential prompts again on every single local rebuild — indefinitely, since a new random channel is minted every time.

This gates ONLY the one-shot eager call at boot — not every future MuxBus interaction on that channel. muxbus.status (reagentx P0/P1 on PR #3248, round 2) instead checks whether muxbus::cloud_subscriber::get_global_subscriber() has been initialized — None until either this flag let boot initialize it (stable/dev channels), or a user explicitly completes muxbus.login on an isolated channel, which lazily initializes it right there. That split is what makes “only prompt once the user actually enables MuxBus” true: skipping the eager boot call must not permanently wall off every other MuxBus code path on that process for its whole lifetime, or an explicit login would “succeed” while silently never opening a WebSocket (reagentx P1, round 2) and the status bar’s 60-second poll would keep hitting Keychain regardless of this flag (reagentx P0, round 2).

Resolution order:

1. AGENTMUX_ISOLATED_MUXBUS=1 / =0 — explicit override, always wins.
2. Otherwise, defaults to isolated (skip the eager reconnect) for a local package channel — AGENTMUX_CHANNEL is set, isn’t "stable", and doesn’t start with "dev-". stable is the real release channel; dev-<branch>[-<clone-id>] (RuntimeMode::Dev’s channel format, below) is task dev’s stable, per-branch channel name — reused across every task dev invocation on that branch, unlike a package build’s channel, which mints a brand-new random hash on literally every single build. A dev session therefore doesn’t have the “never-before-seen app to Keychain every time” problem this flag exists to solve, and isolating it anyway would be a pure regression (reagentx P1 on PR #3248, round 1 + round 2: dev sessions losing automatic MuxBus reconnect, and thus WAN notifications, for the entire session). This is a deliberate narrowing relative to isolated_auth_enabled/isolated_settings_enabled, which isolate dev-* too — those exist to make local testing exercise the real accounts/settings flow, a goal dev-*’s stability doesn’t undermine the same way it undermines this flag’s actual, narrower motivation (avoiding a repeat OS prompt from a randomized per-build identity).
3. If AGENTMUX_CHANNEL isn’t set yet, stays global — conservative default when channel context is unknown, not a guess.

Deliberately a separate flag from AGENTMUX_ISOLATED_AUTH/ AGENTMUX_ISOLATED_SETTINGS, not folded into either — MuxBus’s cloud session is a different kind of credential (one real cloud account, not per-provider OAuth or local UI prefs) and callers should be able to isolate one without the others.