You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Web terminal fails when CSP blocks Ghostty WASM data URL #26001
The web terminal can fail to open because Ghostty loads its WASM runtime from a data:application/wasm;base64,... URL, but OpenCode's web UI CSP does not allow data: in connect-src.
Browser console shows:
Fetch API cannot load data:application/wasm;base64,...
Refused to connect because it violates the document's Content Security Policy.
In some deployments this can then fall through to /ghostty-vt.wasm, which may return the HTML app shell instead of WASM and produce:
WebAssembly.compile(): expected magic word 00 61 73 6d, found 3c 21 64 6f
The embedded UI path also serves index.html with a static CSP that does not include the hash for the inline oc-theme-preload-script, causing this error:
Related to #21088, which covers the embedded UI inline theme preload CSP issue.
Related to #9185 and #9420, which reported Ghostty WASM/data URL failures under CSP.
Related to #5237, which reported asset requests returning index.html and causing MIME/type failures.
OpenCode Version
1.14.38
Also reproduced on latest dev.
Steps To Reproduce
Run opencode web.
Open the web UI in a browser.
Open the terminal.
Check the browser console.
Expected Behavior
The web terminal opens and Ghostty WASM loads successfully.
The embedded HTML CSP should also allow the inline theme preload script that OpenCode injects into index.html.
Actual Behavior
The terminal fails to load because CSP blocks Ghostty's data: WASM URL.
The embedded UI can also block the inline theme preload script because its CSP does not include the script hash.
Suggested Fix
Update the web UI CSP to allow Ghostty's WASM data URL:
connect-src * data:
For embedded HTML, compute the oc-theme-preload-script SHA-256 hash and include it in script-src, matching the proxied HTML behavior.
Also avoid falling back to index.html for missing asset-like paths such as .wasm, .js, .css, and /assets/..., so missing static assets return 404 instead of HTML.
Activity
github-actions commentedon May 6, 2026
This issue might be a duplicate of existing issues. Please check:
These cover the same CSP/Ghostty WASM data URL blocking problem. If your issue is distinct or the fix was reverted, please clarify the difference.
mxl commentedon May 6, 2026
Fixed by #25937