Repository navigation
[bug] Claude code rendering issue in superset terminal #3668
Description
Describe the bug
Hey
been repeatedly facing issue with rendering of claude code output inside superset terminal.
- one pattern is what is in the image above things going gibberish
- second pattern is duplicate repetitive output of claude code, same thing rendered twice or thrice in a row
Reacted by Michael Dodsworth, Andrew Smith, Winston Wu, roundrop, Machiel and Soham Nagi
Activity
github-actions commentedon Apr 23, 2026
Triaged this but could not produce a failing
bun:testreproduction. Writing up what I looked at in case it helps narrow things down.Pipeline investigated (desktop renderer → daemon):
apps/desktop/src/renderer/.../Terminal/v1-terminal-cache.ts— cache-level event gating (streamReady,eventHandler,pendingStreamEvents,pendingLifecycleEvents)apps/desktop/src/renderer/.../Terminal/hooks/useTerminalStream.ts— component-level gating (isStreamReadyRef,pendingEventsRef)apps/desktop/src/renderer/.../Terminal/hooks/useTerminalRestore.ts—flushPendingEvents/maybeApplyInitialStateapps/desktop/src/renderer/.../Terminal/hooks/useTerminalLifecycle.ts—startStream+setStreamReadycall site (lines 604–605) and the reattach path (line 546)apps/desktop/src/main/lib/terminal/daemon/daemon-manager.ts— PTY → batcher → IPC emissionapps/desktop/src/main/lib/data-batcher.ts— 16ms UTF-8-aware batching, usesStringDecoderto keep split multi-byte chars across flushesapps/desktop/src/main/lib/terminal-host/headless-emulator.ts— server-side emulator with chunk-safe tracked-sequence bufferI modeled the event-routing state machine (cache + component queues + mount/unmount/remount) in a unit test and could not manufacture a double-write or out-of-order delivery. Every data event in every scenario I traced ended up written to the xterm sink exactly once. That matches the code paths:
pendingStreamEventsis flushed viarouteEvent, which for data events forwards to the component handler (when mounted) or writes directly to xterm (when unmounted) — never both.pendingEventsRefis flushed only once byflushPendingEventsaftermaybeApplyInitialStatesetsisStreamReadyRef=true.routeEventnever queues a data event while unmounted — it writes directly — so nothing can be replayed on remount.Where I suspect the real cause lives
isAltScreenReattachbranch inuseTerminalRestore.tswrites\x1b[?1049hthenrehydrateSequencesbut intentionally NOTsnapshotAnsi; a subtle interaction with Claude Code's redraw-on-resize flow could leave the screen with half-rendered escape sequences.apps/desktop/src/main/lib/terminal-escape-filter.tsmatches\x1b[3Jin a single chunk. If the 4-byte sequence splits across IPC batches,containsClearScrollbackSequencereturnsfalseon both halves, the headless emulator is not reset, and subsequent cold-restore snapshots include stale content that xterm then re-renders on top of live output — plausible match for the "duplicate repetitive output" symptom.useTerminalCwd.ts/useTerminalModes.tsdon't buffer across chunks for OSC-7 specifically; a split sequence would be silently dropped, but this would only cause a CWD miss, not gibberish.What would actually pin this down
Happy to take another pass with any of that.
Kitenite commentedon May 6, 2026
Related reports (cross-referenced during issue triage — same area, may or may not share a root cause):
wsullivan-dev commentedon May 15, 2026
Terminal output covered in red symbols
Mac OS Tahoe 26.3
M4 Macbook
rikva commentedon May 19, 2026
Same here, started happening more often in the last few days.
distroinfinity commentedon May 19, 2026
hey @Kitenite
first part of my reported issue might me claude code native, check these once:
However, the second related issue of claude output being renders twice inside superset might be an unhandled or a leak in superset terminal orchestrator.
Issue persists as of today May 19, as well.
Thanks for looking into it!
Kitenite commentedon Jul 11, 2026
Closing as a duplicate of #5605, the consolidated tracker for stale
terminal-renderingissues from the July 2026 stale-issue sweep (no activity since 2026-06-01). If this still applies on a current build, comment on #5605 and we'll reopen.