feat(desktop): route beta channel to dev backend

[kodjima33]

Summary

• Beta channel of the production bundle (com.omi.computer-macos) now routes to the dev backend (api.omiapi.com Python + dev Cloud Run desktop-backend), matching mobile's TestFlight → staging pattern.
• Stable channel and non-prod bundles are unchanged.
• New OMI_FORCE_DEV_BACKENDS=1 env override lets a named test bundle opt into dev backends without flipping its channel — handy for side-by-side validation.

Why this won't repeat the PR #7014 outage

PR #7014 (April 2026) was reverted because the dev backend was wired to the based-hardware-dev Firebase project, so beta users signed in as fresh empty UIDs (e.g. caLCFj7… instead of prod's viUv7Gtdo…). The dev backend infra has since been moved onto prod Firebase. Verified against the live deployments:

$ gcloud run services describe backend --project=based-hardware-dev …
  FIREBASE_PROJECT_ID = based-hardware
  FIREBASE_AUTH_DOMAIN = based-hardware.firebaseapp.com
  GOOGLE_CLOUD_PROJECT = based-hardware
  FIREBASE_API_KEY = AIzaSyA88g…   (matches prod)
  SERVICE_ACCOUNT_JSON.project_id = based-hardware
  client_email = nik-164@based-hardware.iam.gserviceaccount.com

$ gcloud run services describe desktop-backend --project=based-hardware-dev …
  FIREBASE_PROJECT_ID = based-hardware
  FIREBASE_API_KEY = AIzaSyA88g…   (matches prod)

So custom tokens minted by the dev backend resolve to the same UID the user has on prod, and reads/writes hit prod Firestore.

Test plan

• swift test --filter APIClientRoutingTests (46/46 passing)
• Codemagic builds Beta DMG from this branch on merge
• Install Beta DMG on Mac mini, sign in with kodjima33@gmail.com
• Confirm auth_userId defaults shows the prod UID (viUv7Gtdo…), not a fresh one
• Confirm existing conversations + memories load
• Record a new conversation; confirm it appears in prod Firestore for the prod UID
• Confirm stable channel of the same prod bundle keeps using api.omi.me

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR re-enables beta-to-dev backend routing for the production macOS bundle (com.omi.computer-macos), which was previously locked to return false after the PR #7014 outage. It also introduces an OMI_FORCE_DEV_BACKENDS env override that lets any bundle opt into dev backends without changing its update channel.

• Core routing logic: shouldUseDevelopmentBackends now returns true when the production bundle is on the beta channel, matching mobile's TestFlight → staging pattern. A new isAffirmative helper handles \"1\"/\"true\"/\"yes\" for the env override.
• Safety rationale: The dev backend has since been migrated to the prod Firebase project, so custom tokens resolve to the same UID as prod and Firestore reads/writes hit prod data.
• Test coverage: 46 routing tests updated; stable channel, non-production bundles, and the force override path all have dedicated assertions.

Confidence Score: 4/5

Safe to merge; the routing logic is correct, well-tested, and well-commented with the historical context needed for future maintainers.

The routing logic is narrowly scoped and all test cases pass. The only rough edges are a log message that now misfires under the force-override path, and a small gap in isAffirmative test coverage — neither affects correctness of the routing decisions.

desktop/Desktop/Sources/DesktopBackendEnvironment.swift — the applyReleaseChannelDefaults() log message should be updated to distinguish the force-override trigger path from the beta-channel path.

Important Files Changed

Filename	Overview
desktop/Desktop/Sources/DesktopBackendEnvironment.swift	Re-enables beta-to-dev backend routing for the production bundle and adds OMI_FORCE_DEV_BACKENDS env override; logic is correct but the log message in applyReleaseChannelDefaults() becomes inaccurate when routing is triggered by the override rather than the beta channel.
desktop/Desktop/Tests/APIClientRoutingTests.swift	Well-structured test updates cover the main routing cases; missing coverage for the "yes" affirmative value and explicit rejection of "false"/"no" for the forceOverride parameter.
desktop/CHANGELOG.json	Adds a user-facing changelog entry for the beta dev-backend routing change; no issues.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[shouldUseDevelopmentBackends called] --> B{OMI_FORCE_DEV_BACKENDS\nis affirmative?}
    B -- Yes --> C[return true\nRoute to dev backends]
    B -- No --> D{bundleIdentifier ==\ncom.omi.computer-macos?}
    D -- No --> E[return false\nRoute to prod backends]
    D -- Yes --> F{normalizedChannel ==\nbeta or staging?}
    F -- No --> E
    F -- Yes --> C
    C --> G[applyReleaseChannelDefaults:\nsets OMI_PYTHON_API_URL to api.omiapi.com\nsets OMI_DESKTOP_API_URL to dev Cloud Run]
    E --> H[pythonBaseURL to api.omi.me\nrustBackendURL to prod Cloud Run]

Loading

Comments Outside Diff (1)

1. desktop/Desktop/Sources/DesktopBackendEnvironment.swift, line 93-99 (link)

   Stale log message when force-override triggers dev routing

   applyReleaseChannelDefaults() logs "beta channel using development backends…" but will now also fire when OMI_FORCE_DEV_BACKENDS=1 is set on a non-beta or non-production bundle. If someone uses the override on a stable dev build to debug a specific issue and then checks the logs, the message will mislead them into thinking the routing was triggered by channel assignment rather than the env override. A simple conditional or a second log branch would keep the message accurate.

_{Reviews (1): Last reviewed commit: "feat(desktop): route beta channel to dev..." | Re-trigger Greptile}

[greptile-apps]

isAffirmative "yes" branch and non-affirmative values are untested

isAffirmative accepts "yes" in addition to "1" and "true", but testForceOverrideEnablesDevelopmentBackendsForAnyBundle never exercises it. Likewise, "false" and "no" are silently rejected by the function but are never asserted as false in the test. A future refactor that trims the accepted set or changes the rejection logic would have no test catching the regression.