Repository navigation
[Bug]: Local environment can't be turned back on once disabled (toggle hidden behind "No environment selected") #17013
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- In the desktop app, have at least one remote environment connected.
- Open Settings → Connections and turn off Local environment in the "This machine" card, then confirm.
- After the restart, go back to Settings → Connections to turn it back on.
Expected behavior
The "This machine" card still shows the Local environment switch, so the local environment can be turned back on.
Actual behavior
The "This machine" card shows only "No environment selected — Connect an environment to view its settings and access." The switch isn't rendered anywhere. Selecting or using a connected remote environment doesn't bring it back, and searching settings for "Local environment" opens the same empty card.
The chat empty state says "turn the local environment back on in Connections", but the UI gives no way to do that.
Cause (from the shipped client bundle): in the Connections settings route, the connections-environment section branches on the primary environment id. When it's null (which it always is while the local environment is disabled), it renders the "No environment selected" placeholder. The local environment toggle component (the one that calls window.desktopBridge.setLocalEnvironmentEnabled) is only rendered in the other branch, so it can't be reached once local is off.
Suggested fix: render the local environment toggle in the "No environment selected" branch too (or whenever desktopBridge.getLocalEnvironmentEnabled?.() === false).
Impact
Major degradation or frequent failure
Version or commit
0.0.46-nightly.20261007.2787
Environment
Desktop app (nightly), connected to one remote environment over Tailscale.
Workaround
Open DevTools in the desktop app and run:
await window.desktopBridge.setLocalEnvironmentEnabled(true)The local backend restarts and the "This machine" card (with the switch) comes back.
Activity
juliusmarminge commentedon Oct 8, 2026
Note
Grok responding on behalf of Julius.
Thanks for the detailed report and the workaround. I confirmed this by reading the code on
mainat14fe015. I haven't reproduced it in a running app.Cause
ConnectionsSettings, theconnections-environmentsection now branches onprimaryEnvironmentId !== null(ConnectionsSettings.tsx#L3669-L3672).<LocalEnvironmentSetting />is only rendered inside that branch (#L3712). Thenullbranch renders only the "No environment selected" row plus the optional cloud link row (#L4091-L4100).null.primaryEnvironmentIdAtomreturns the first catalog entry whose target is aPrimaryConnectionTarget(primaryEnvironment.ts#L5-L12). The only place that builds one is the platform connection source (platform.ts#L354), and that source emits no registrations whenisLocalEnvironmentDisabled()(platform.ts#L570-L573). The comment onreadPrimaryEnvironmentTargetsays the same thing (target.ts#L306-L311).connections-environmenttarget (settingsSearch.ts#L825-L831), so it lands on the empty card. Meanwhile, the chat empty state tells users to "turn the local environment back on in Connections" (_chat.index.tsx#L119-L121).When it started
When #9194 added the toggle, the branch was
desktopBridge || canManageLocalBackend, so desktop always reached it. #9786 (feat(auth): separate environment administration permissions, commit28ce9d1) changed it toprimaryEnvironmentId !== nulland added the "No environment selected" placeholder. That matches your 2026-10-07 nightly.Suggested fix (untested)
Render
<LocalEnvironmentSetting />in thenullbranch too, or bring the branch back todesktopBridge || primaryEnvironmentId !== nullfor this row. The component already returnsnullwhendesktopBridge.setLocalEnvironmentEnabledis missing (LocalEnvironmentSetting.tsx#L22-L27), so browsers and hosted builds stay unaffected. A render test with the local environment off would catch this if it regresses again. None of the recent open PRs I checked that touchConnectionsSettings.tsxchange this branch.Workaround
Your DevTools workaround is valid. The desktop preload exposes
window.desktopBridge.setLocalEnvironmentEnabled(preload.ts#L113-L116). The handler saves the setting and relaunches the app when the value changes (localEnvironment.ts#L18-L30):