tiletopia

I'll take a look. That symptom — typed characters lagging, then the display "snapping" correct after a pause — smells like a buffering/flush issue in the PTY output path. Let me read the session memory first (per the project agreement), then trace the data flow.

• Read /mnt/d/dev/tiletopia/memory.md 270ms 48.7 KB

• Bash find /mnt/d/dev/tiletopia/src /mnt/d/dev/tiletopia/src-tauri/src -type f \( -name '*.ts' -o -name '*.tsx' -o -name '*.rs… 135ms 1.5 KB

• Read /mnt/d/dev/tiletopia/src/components/XtermPane.tsx 41ms 26.2 KB

• Read /mnt/d/dev/tiletopia/BUGS.md 18ms 11.0 KB

• Bash cat /mnt/d/dev/tiletopia/package.json 42ms 1.0 KB

• ToolSearch select:WebSearch,WebFetch 3ms 100 B

• WebSearch xterm.js canvas addon cursor stuck artifact typing gap issue 7.7s 2.5 KB

• WebSearch @xterm/addon-canvas deprecated cursor rendering bug 7.2s 2.5 KB

• WebSearch Claude Code terminal input cursor gap stuck typing space disappears 8.2s 2.9 KB

• WebSearch xterm.js 5.5 canvas renderer stale cursor cell not cleared typing fast github issue 6.9s 2.4 KB

• AskUserQuestion questions 159.2s 582 B

• WebSearch anthropics claude-code issue input box typing fast cursor lags behind catches up after pause render throttle 10.3s 3.5 KB

• Edit error /mnt/d/dev/tiletopia/memory.md 19ms 96 B

• Read /mnt/d/dev/tiletopia/memory.md 12ms 2.8 KB

• Edit /mnt/d/dev/tiletopia/memory.md 78ms 138 B

• Bash git add memory.md && git commit -m "memory: log new claude-pane cursor-gap bug report + diagnosis plan" && git push 3.0s 197 B

Here's my assessment after digging through the code, the project history, and the upstream trackers.

**TL;DR: I think this is most likely Claude Code's own TUI, not tiletopia — but there's a 2-minute test that settles it.**

**What the symptom tells us.** You only see it inside `claude`, and it takes a few seconds to self-correct. That timing rules out the renderer-level cursor artifacts we've fought before (the 2026-05-28 ghost cursor was the DOM renderer leaving a stale block — fixed by the canvas addon; a renderer/blink glitch corrects sub-second). A multi-second lag that "snaps" correct when you pause is the signature of Claude Code's input loop falling behind: its TUI runs rendering, stream parsing, and stdin draining all on one event loop, and under load it buffers your keystroke echo, leaving the cursor stuck/gapped until a catch-up repaint flushes everything at once. This exact behavior is reported upstream in other terminals — [#58498](https://github.com/anthropics/claude-code/issues/58498) (input frozen, then dumps at once), [#63504](https://github.com/anthropics/claude-code/issues/63504) (host CPU pressure starves the input loop on Windows), [#29366](https://github.com/anthropics/claude-code/issues/29366), and [#2847](https://github.com/anthropics/claude-code/issues/2847). Notably, running many parallel claude sessions — tiletopia's whole reason to exist — is precisely the CPU-contention condition #63504 describes.

**The decisive test (only you can run it):** open Windows Terminal, start `claude` in the same distro/project, get a session going, and type fast mid-session. Also worth noting whether the bug in tiletopia correlates with how many panes are busy.

- **Reproduces in Windows Terminal too** → it's Claude Code upstream; nothing for tiletopia to fix (worth a `claude --version` check / upstream issue instead).
- **Only happens in tiletopia** → the prime suspect becomes our renderer: `@xterm/addon-canvas` is now **deprecated upstream** (no more fixes, removed in xterm v6, [WebGL is the recommended path](https://www.npmjs.com/package/xterm-addon-canvas)). The fix would be a renderer change — WebGL with context-pool management for the ~16-context WebView2 cap (e.g. WebGL on the focused/visible panes, canvas elsewhere), or re-evaluating the much-improved 5.5 DOM renderer against the old ghost-cursor repro.

One thing I'd also like to know from the test: whether a typed space is ever *actually* eaten (check the submitted prompt afterwards). Everything above assumes it's visual-only; a genuinely lost character would point at the input path instead, which would be a different investigation.

I've logged the symptom, hypothesis, and test plan in `memory.md` (committed and pushed, `738fa2e`), so whichever way the test goes we can pick it up cleanly. Side note from this dig: the canvas addon's deprecation means a renderer migration is coming for us eventually regardless — `BUGS.md` from today's audit is also sitting untracked with some real findings (H1–H5) whenever you want to tackle those.