[Bug]: Settings changes in the desktop app don't apply to a remote environment #7500

Activity

1. christhomas commented on Sep 14, 2026

   

   christhomas

   on Sep 14, 2026

   More actions

   Same root cause, different surface: this also affects source control providers, and I have
   measurements that pin down where the call stops.

   Setup: macOS desktop, remote environment (Raspberry Pi 5, Debian 12 arm64) over T3 Connect
   rather than Tailscale. Server t3 serve 0.0.41-nightly.20260914.1707, running as a systemd system
   unit under a dedicated service account.

   What happens

   In Add Project, with the remote environment selected, GitHub shows "Setup Required". Opening
   Settings → Source Control gives a single panel with no environment picker, and it reports the
   laptop's CLIs.

   The version numbers prove which machine is being read

   Shown in the panel:   gh 2.97.0  (2026-07-31)   <- my MacBook, authenticated via keyring
   Installed on server:  gh 2.100.0 (2026-09-03)   <- authenticated via ~/.config/gh/hosts.yml
   

   Different builds, so the panel cannot be reporting the remote.

   The server is never asked at all

   gh appears zero times in a 2.7 MB server.trace.ndjson, and there are no
   sourceControl / providerScan / githubCli entries anywhere in it. Same in journald. That
   covers two full service restarts performed after gh was installed and authenticated, so this
   is not a stale scan that a restart would clear — the call never arrives.

   The server side is demonstrably fine

   Run with the service's exact environment (HOME, PATH, GH_TOKEN/GITHUB_TOKEN unset):

   gh resolves to   ~/.local/bin/gh
   gh auth status   "Logged in to github.com account ..."   exit code 0
   token scopes     gist, read:org, repo, workflow
   

   And git works end to end on the server: I cloned a private repo into the workspace as the service
   account, committed, pushed a branch to GitHub, and deleted it again. So the capability is present
   and only the reporting is wrong.

   Where it looks like it stops

   The environment server implements source-control discovery and exposes it per environment, and the
   client's readiness query takes an environmentId — so both halves of the plumbing exist. What
   appears to be missing is the Settings panel scoping: it presents one unscoped view built from the
   local environment, so a remote environment's providers can never be discovered, and "Rescan server
   environment" has no visible way to target anything but the local machine.

   This is the same shape as the original report — the desktop reading local capabilities and never
   querying the remote — which is why I think it belongs here rather than as a separate issue. The
   requested fix in the original report (an environment filter on the settings pane) would resolve
   this case too.

   Workaround, for anyone else hitting this

   In Add Project, paste the full clone URL instead of choosing GitHub from the provider list. The
   URL option is not gated by provider discovery, and the clone then runs server-side with the
   server's own git credentials. Ordinary push and pull work normally afterwards, since those are
   plain git invocations. I have not tested whether pull-request creation is gated by the same
   readiness map.
2. juliusmarminge commented on Oct 2, 2026

   

   juliusmarminge

   on Oct 2, 2026

   Member

   More actions

   Thanks for taking the time to report this and provide the details. We revisited it during the orchestrator V2 cleanup.

   Settings now resolve explicit environment/project scopes. General model choices use the selected environment providers, and Source Control discovery queries that environment ID. The original primary-local-only settings architecture has been replaced.

   I’m closing this based on the current source and the evidence in this thread.

   Source reviewed.

   No remote UI pass; grouped-project representative behavior is a separate narrower concern.

   If you still hit this on a current build, please reply with the app/server versions and the steps that reproduce it. We can reopen this if the original problem is still there.
3. juliusmarminge

   closed this as completedon Oct 2, 2026