AI network proxy is an account-level cloud setting: saving it on one machine instantly breaks AI chat on all other machines in different networks (no warning, no per-machine scope)

Bug Reports
1

Issue Description

Qoder’s AI proxy configuration (Qoder IDE Settings → Advanced → Network Proxy) is stored as a single account-level value in the cloud and pushed to every machine logged in with the same account — near real-time, no restart/reload required.

In enterprise intranet environments, machines of one user often sit in different network zones: some can reach the corporate proxy directly, while others (e.g., restricted shared servers) can only reach an internal relay. One global proxy value cannot serve both.

Saving the proxy on Machine A immediately overwrites the daemon config (~/.config/Qoder/<account-hash>/SharedClientCache/cache/app-config.json → httpProxy) on Machine B while B’s daemon is running. B then cannot fetch AI model config and all AI chats fail.

Three compounding problems:

  1. No warning that this setting syncs account-wide. The settings card even reads “Proxy configuration synced from the editor’s http.proxy setting”, suggesting it is a local/following setting.
  2. Opaque failure symptoms: UI shows “Request timeout” within 2–3 seconds; logs show no model config found / sql: no rows in result set. Nothing indicates the config was overwritten from another machine.
  3. On older client (1.24.2) there is no UI to edit this value at all — the cloud value becomes uncorrectable dead data that re-breaks the AI after every daemon cold start.

Steps to Reproduce

  1. Prepare two remote hosts logged into the same Qoder account, in different network zones:
    • Machine A: can reach proxy P1 (e.g., corporate proxy)
    • Machine B: cannot reach P1; can only reach P2 (e.g., internal relay proxy). AI works on B via P2.
  2. On Machine B: Qoder IDE Settings → Advanced → Network Proxy = P2, save. Verify AI chat works on B.
  3. On Machine A: open the same settings page, set Network Proxy = P1, save.
  4. Within ~1 minute (B needs no restart/reload), send a message in a new AI chat on Machine B.

Observed evidence: B’s app-config.json mtime was overwritten at the exact minute A saved; the daemon (still running) then pointed httpProxy to P1 and model-config fetch failed (no model config found in remoteexthost.log).

Expected Behavior

  • AI proxy configuration should support per-machine (or per-network-environment) scope, like VS Code’s http.proxy User/Remote layering — the editor layer already works this way, but the AI layer is a single global value.
  • At minimum, a warning before saving: “This proxy will be synced to all devices on your account”.

Actual Behavior

  • Saving on A pushed P1 to the cloud and then to B’s daemon within seconds, with B’s daemon running.
  • All AI chats on B fail in 2–3 seconds (“Request timeout”); log shows no model config found because B cannot reach P1.
  • No UI indication on B that its AI proxy was changed remotely.
  • Recovery requires manually saving a reachable proxy again on some machine (which then breaks whichever machine cannot reach the new value — the single-value design makes full recovery impossible in heterogeneous networks).

Screenshots / Screen Recordings

Operating System

Local client: Windows 10 (company managed)
Remote hosts: Linux x86_64 (CentOS 7), via Remote SSH

Current Qoder Version (Menu → About Qoder → Copy)

版本: 1.25.1
VSCode 版本: 1.106.3 (system setup)
提交: 6e2bf8bcc03df7436277ff8d1f74855c3dbee208
日期: 2026-08-18T14:07:01.612Z
Electron: 42.2.0
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Windows_NT x64 10.0.17763