Pre-boot branding script reads window.__CONSOLE_SERVER_URL (set nowhere); modules read VITE_SERVER_URL — dev setups fetch runtime/config against the wrong origin

[os-zhuang]

Filed by the PM on behalf of the #5544 dev agent, whose search-before-file step was blocked by a GitHub API rate limit. Found during PR #5658.

The pre-boot branding script inlined at apps/console/index.html:49 reads window.__CONSOLE_SERVER_URL — which is set nowhere in this repository — while every module-side consumer reads import.meta.env.VITE_SERVER_URL (apps/console/src/main.tsx:65).

Consequence: a dev setup that points the console at a separate server via VITE_SERVER_URL has the two code paths targeting different origins — the inline script fetches /api/v1/runtime/config against the Vite dev origin, 404s, and early branding silently never applies. Pre-existing, dev-only: both resolve to '' in production builds (same-origin), which is why PR #5658's dedup works there.

Not graded — severity is a triage call. The narrow fix is to inject the same value the modules read (or drop the inline fetch now that PR #5658 shares the in-flight promise between the two callers, which may make the inline script's fetch redundant entirely — worth checking before patching the variable).

[huangyiirene]

Concentration-round first-touch (triage seat): promoted finding → pm:queue, Bug (label bug — the script reads a variable set nowhere in the repo, and dev-setup branding silently never applies), size S. Check-first clause per the card's own note: establish whether PR #5658's shared in-flight promise makes the inline fetch redundant entirely — if yes, deleting the inline fetch is the fix (less code, one origin); only if the pre-boot timing is measurably load-bearing does the variable-injection repair apply. Either way the two paths end up reading one value.

---

Generated by Claude Code