1jehuang / 1jehuang/jcode

Windows TUI: live render corruption (leaked ANSI escapes, stray glyphs, overlapping prompts) with fragmented input

Open
#501 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

autonomous: no bug needs-info priority: high triage: unclear
Dominant language
Rust
Stars
19.9k
Forks
2.3k
Avg merge
2d 7h
Merged PRs (30d)
30

Description

Summary

On Windows, using Alacritty - the interactive TUI intermittently corrupts its own render: leaked ANSI escape fragments show up as literal text in the transcript (e.g. ;18;49m-), stray glyphs appear (a run of blue @@@@@@@@@@# characters), and prior turns get scrambled/overwritten. In the same episode, typed input was split across multiple prompts as tiny fragments (i, ye, rt u, rort, bahs), suggesting keystrokes were being dropped or mis-batched while the screen was in a bad state.

This is distinct from #498 (launch crash / garbled panic text). Here jcode is fully running mid-session and the live TUI redraw is corrupted; there is no crash.

When using Git Bash - all works as expected.

Environment

  • OS: Windows 10.0.26200.8875 (x86_64)
  • Terminal: TERM=xterm-256color (WT_SESSION/ConEmuANSI unset in the captured shell)
  • jcode version reported in session context: v0.47.0 (f7f5898c)

What I saw (from screenshot)

1> i
The user sent just "i" which looks like an accidental or incomplete message...
Did your message get cut off? Let me know what you'd like help with.
  5.2s . 42.7 tps . ↑207 ↓95
1
/2> ye                    e skill                                   ;18;49m-
:  connecting... 2s . https
3..  [yellow block]  @@@@@@@@@@#   <- rendered as literal blue text

Notable artifacts:

  • ;18;49m- — tail of an SGR escape (\e[...;18;49m) printed literally, so VT output is being emitted where it is not being interpreted, or a styled span is being split mid-escape during redraw.
  • @@@@@@@@@@# in blue — looks like a spinner/placeholder or buffer cell fill leaking into the transcript.
  • Prompt lines 1>, /2>, 3.. overlap with stale content (e skill, connecting...) from other regions, i.e. the diff/erase between frames is not clearing old cells.

Input fragmentation

During the same episode, single words arrived as separate user turns: i, then ye, then rt u, then rort, then bahs. Either keystrokes were dropped or the input line was being committed prematurely while the screen was mid-corruption.

Suspected areas

  • Windows console VT handling: styled spans split across redraw chunks can emit a partial escape (;18;49m) as literal text if a write is truncated or if VT mode toggles mid-frame.
  • Frame diffing not clearing stale cells on Windows conhost/Terminal, leaving @@@@@@@@@@#-style filler and overlapping prompts.
  • Possible interaction with the spinner/connecting... status widget writing outside the managed draw region.

Repro

Not yet deterministic. Observed on Windows during normal chat with quick successive short inputs while a connecting.../spinner status was active. Relevant log C:\Users\<user>\.jcode\logs\jcode-2026-07-17.log shows only auth/model errors, no render/panic entries, consistent with a pure TUI-draw bug.

Attachment

Screenshot of the corrupted render available from the reporter.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the corruption on Windows with Alacritty and quick successive inputs while the connecting spinner is active, then inspect the Windows VT handling, frame diff/erase path, and spinner draw region described in the report. Check C:\Users<user>.jcode\logs\jcode-2026-07-17.log for related context and compare against Git Bash; done means redraws leave no escape fragments or stale glyphs and input remains in one prompt.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.