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
Took a look at this — based on the description ("gibberish text and symbols" in both the terminal and Claude views, fixed temporarily by resizing or reopening the window), this looks like an xterm.js WebGL/canvas font-atlas state corruption: a refresh re-measures glyphs and gets the renderer back in sync.
Relevant code I reviewed:
apps/desktop/src/renderer/screens/main/components/WorkspaceView/ContentView/TabsContent/Terminal/helpers.ts — WebGL addon load + onContextLoss handler that disposes and calls xterm.refresh(...). It does not set suggestedRendererType = "dom" after a context loss, so a later terminal will retry WebGL and hit the same path.
apps/desktop/src/renderer/lib/terminal/terminal-addons.ts — same WebGL pattern for runtime-managed terminals.
apps/desktop/src/renderer/lib/terminal/appearance/index.ts — font sanitization. The module-level monospaceCheckCache caches results from ctx.measureText; if a custom monospace font hasn't finished loading at first check time, the canvas measures with the proportional fallback and the (incorrect) "not monospace" result is cached for the lifetime of the renderer.
I couldn't write a reproduction test because:
The symptom is a GPU/canvas rendering glitch — bun:test runs in Node with a minimal DOM stub, no real canvas/WebGL, so the failure mode isn't observable.
The trigger is timing- and environment-dependent (font loading, GPU context state, DPR changes), which I can't drive deterministically without a real Electron + browser harness.
The screenshot wasn't enough to narrow it to a specific glyph-substitution pattern (e.g. icon font vs. ligature vs. atlas tearing) without seeing the affected characters and the exact context.
To move this forward, could you share:
OS + version (macOS 14? Windows 11? Linux distro/Wayland or X11?)
Display setup — external monitor, mixed-DPI, recent display change before it appeared?
Superset version (Help → About) and roughly when the last update happened.
DevTools console output when the glitch is visible (View → Toggle Developer Tools, or Cmd+Option+I) — any WebGL context-loss warnings or font-related errors would pin this down quickly.
If you can: a few seconds of screen recording, or a sample of the gibberish text copy-pasted (the copy buffer holds the real characters even when rendering is glitched — that would tell us if it's a font/glyph substitution or a renderer artifact).
Most likely root cause is a WebGL context-loss path that isn't fully resetting the renderer. As a workaround in the meantime: closing the bad pane and opening a new one (you already noted this works) avoids it until a fix lands.
Also found some people complaining in Claude subreddit, but what's more interesting that I had issue in terminal (and other guy with Cursor), so that leads me to believe it's not Claude-only issue.
When this gibberish text and symbols problem happens to me, I just resize the windows, or even just the terminal panel size, and it fixes it. I think the resize is forcing the terminal to rerender the text properly. But it's true that the bug is happening a lot these days.
Just want to add that this is pervasive on my end too — the garbled/illegible text shows up regularly across both the terminal and Claude Code, and a window resize / new window only clears it temporarily. Saw the note that it's an upstream xterm.js issue with the candidate fix in xtermjs/xterm.js#5883 — would love to check in and see how things are going on getting a fix shipped. Thanks for the work on this!
Issue not fixed, this is happening again.
Still reproducible on Superset Desktop 1.14.3 on macOS.
This installation includes @xterm/xterm 6.1.0-beta.220 and@xterm/addon-webgl 0.20.0-beta.219, so the atlas-merge fix from #4893 is present.
Resizing the pane/window forces a repaint and restores the correct glyphs temporarily.
Activity
saddlepaddle commentedon May 15, 2026
Hi there, apologies this is high priority for us! We'll look into it immediately 👍🏼
github-actions commentedon May 15, 2026
Took a look at this — based on the description ("gibberish text and symbols" in both the terminal and Claude views, fixed temporarily by resizing or reopening the window), this looks like an xterm.js WebGL/canvas font-atlas state corruption: a refresh re-measures glyphs and gets the renderer back in sync.
Relevant code I reviewed:
apps/desktop/src/renderer/screens/main/components/WorkspaceView/ContentView/TabsContent/Terminal/helpers.ts— WebGL addon load +onContextLosshandler that disposes and callsxterm.refresh(...). It does not setsuggestedRendererType = "dom"after a context loss, so a later terminal will retry WebGL and hit the same path.apps/desktop/src/renderer/lib/terminal/terminal-addons.ts— same WebGL pattern for runtime-managed terminals.apps/desktop/src/renderer/lib/terminal/appearance/index.ts— font sanitization. The module-levelmonospaceCheckCachecaches results fromctx.measureText; if a custom monospace font hasn't finished loading at first check time, the canvas measures with the proportional fallback and the (incorrect) "not monospace" result is cached for the lifetime of the renderer.I couldn't write a reproduction test because:
bun:testruns in Node with a minimal DOM stub, no real canvas/WebGL, so the failure mode isn't observable.To move this forward, could you share:
Most likely root cause is a WebGL context-loss path that isn't fully resetting the renderer. As a workaround in the meantime: closing the bad pane and opening a new one (you already noted this works) avoids it until a fix lands.
komly commentedon May 15, 2026
Same problem multiple times a day. Please fix. Only restart helps.
javierjavier commentedon May 15, 2026
@komly per @itsJoKr resize also temporarily fixes
itsJoKr commentedon May 15, 2026
itsJoKr commentedon May 16, 2026
Also found some people complaining in Claude subreddit, but what's more interesting that I had issue in terminal (and other guy with Cursor), so that leads me to believe it's not Claude-only issue.
pgt2195 commentedon May 16, 2026
When this gibberish text and symbols problem happens to me, I just resize the windows, or even just the terminal panel size, and it fixes it. I think the resize is forcing the terminal to rerender the text properly. But it's true that the bug is happening a lot these days.
jgreer013 commentedon May 16, 2026
Such a funny bug
Kitenite commentedon May 17, 2026
it's unfortunately an xterm issue, same reports in vscode as well. we're trying to see if we can fix it upstream
jnelken commentedon May 19, 2026
Please comment and vote this potential fix:
fix(desktop): bump @xterm/* to beta.220 for upstream WebGL atlas-merg…
KirkPX commentedon May 26, 2026
Just want to add that this is pervasive on my end too — the garbled/illegible text shows up regularly across both the terminal and Claude Code, and a window resize / new window only clears it temporarily. Saw the note that it's an upstream xterm.js issue with the candidate fix in xtermjs/xterm.js#5883 — would love to check in and see how things are going on getting a fix shipped. Thanks for the work on this!
AviPeltz commentedon Jul 10, 2026
I believe this was fixed let me know if you see this issue persisting
VXNCXNX commentedon Jul 11, 2026
Issue not fixed, this is happening again.
Still reproducible on Superset Desktop 1.14.3 on macOS.
This installation includes @xterm/xterm 6.1.0-beta.220 and@xterm/addon-webgl 0.20.0-beta.219, so the atlas-merge fix from #4893 is present.
Resizing the pane/window forces a repaint and restores the correct glyphs temporarily.