Repository navigation
OpenCode Web UI serves stale v1.1.33 frontend from CDN despite local version upgrade #10226
Description
Environment
- OS: Windows
- OpenCode version: 1.1.34 (also tested 1.1.32, 1.1.30 - same issue)
- Installation: bun install -g opencode-ai@latest
Problem
opencode serve renders blank page with RangeError: Maximum call stack size exceeded. This is the same bug reported in
OpenCode Desktop blank in v1.1.33 #10136, which was supposedly fixed in fix(desktop): Fixed a reactive feedback loop in the global project cache sync #10139 and released in v1.1.34.
However, upgrading to v1.1.34 does NOT fix the issue. Neither does downgrading to v1.1.32 or v1.1.30.
Root Cause Analysis
The frontend assets are NOT embedded in opencode.exe. They are fetched from Cloudflare R2 CDN at runtime:Evidence Command Result exe contains R2 CDN reference grep -a "r2.cloud" opencode.exe 4 matches exe does NOT contain JS bundle grep -a "index-Bj9zfj-u.js" opencode.exe 0 matches Response has Cloudflare headers curl -I .../assets/index-Bj9zfj-u.js Server: cloudflare, CF-RAY: ... JS file lacks v1.1.34 fix curl .../index-Bj9zfj-u.js | grep -c "solid-js" 0 (should contain untrack from solid-js) Only "untrack" found is theme-related grep -oE ".{30}untrack.{30}" markup.untracked (syntax highlighting, NOT the fix) Evidence Chain PR fix(desktop): Fixed a reactive feedback loop in the global project cache sync #10139 fix added: import { untrack } from "solid-js" // ... const cachedLength = untrack(() => projectCache.value.length) But the JS bundle currently served from CDN does NOT contain this fix. The file hash Bj9zfj-u hasn't changed, meaning CDN is still serving the v1.1.33 buggy bundle. Reproduction opencode --version # Shows 1.1.34 opencode serve --port 4096
In another terminal:
2966146fc4dc08361b65fca02b2cd08c (same hash regardless of local version)
curl -s http://127.0.0.1:4096/assets/index-Bj9zfj-u.js | grep -c "solid-js"
0 (fix is missing)
curl -sI http://127.0.0.1:4096/assets/index-Bj9zfj-u.js | grep Server
Server: cloudflare
Solution
Purge Cloudflare R2/CDN cache, or trigger a new Vite build with a different content hash for the v1.1.34 frontend
bundle.
Reacted by Jean-Claude, Daniel Vélez, blu3gui7ar and webmalex
Activity
github-actions commentedon Jan 23, 2026
This issue might be a duplicate of existing issues. Please check:
These all appear to be manifestations of the same underlying CDN/frontend asset issue described in your #10226 report. Your comprehensive root cause analysis (CDN serving stale v1.1.33 bundle with missing solid-js untrack fix) is likely the explanation for all these reported symptoms.
Feel free to ignore if your case has different circumstances.
ndtn-dev commentedon Jan 23, 2026
Great debugging. Can confirm the version-independence finding from different environments:
Posted my findings in #10202 that align with this: #10202 (comment)
nukeop commentedon Feb 3, 2026
So that's why local upgrades don't fix already fixed bugs sometimes. I'm getting this too sometimes.
favorPotato commentedon Feb 8, 2026
Yes, and I really can't imagine why local services need to connect to CloudFlare, and what is the significance of doing so
thdxr commentedon Mar 26, 2026
Fixed by #19299 - This issue was caused by CDN caching serving stale frontend assets that didn't match the local server version. Version 1.3.3 is going out now and embeds the WebUI directly in the binary, eliminating CDN caching issues and ensuring frontend assets always match the server version.
thdxr commentedon Mar 26, 2026
Closing as fixed by #19299