fix: don't timeout-flush unambiguous escape sequences split across reads by Hona · Pull Request #819 · anomalyco/opentui

Hona · 2026-03-16T00:25:12Z

Summary

Stop timeout-flushing escape sequences once the framing byte is seen (CSI, OSC, DCS, APC, SS3, mouse states)
Only esc and esc_recovery states still honor forceFlush since a lone ESC is genuinely ambiguous

Fixes #818

pkg-pr-new · 2026-03-16T00:27:25Z

@opentui/core

npm i https://pkg.pr.new/@opentui/core@1fba2e7

@opentui/react

npm i https://pkg.pr.new/@opentui/react@1fba2e7

@opentui/solid

npm i https://pkg.pr.new/@opentui/solid@1fba2e7

@opentui/core-darwin-arm64

npm i https://pkg.pr.new/@opentui/core-darwin-arm64@1fba2e7

@opentui/core-darwin-x64

npm i https://pkg.pr.new/@opentui/core-darwin-x64@1fba2e7

@opentui/core-linux-arm64

npm i https://pkg.pr.new/@opentui/core-linux-arm64@1fba2e7

@opentui/core-linux-x64

npm i https://pkg.pr.new/@opentui/core-linux-x64@1fba2e7

@opentui/core-win32-arm64

npm i https://pkg.pr.new/@opentui/core-win32-arm64@1fba2e7

@opentui/core-win32-x64

npm i https://pkg.pr.new/@opentui/core-win32-x64@1fba2e7

commit: 1fba2e7

Copilot

Pull request overview

This PR fixes issue #818 where CSI (and similar) escape sequences split across two stdin reads were being prematurely flushed as "unknown" responses due to the 10ms timeout. The timeout exists to detect lone ESC keypresses, but once a framing byte is seen (e.g., ESC[ for CSI), the sequence is unambiguous and should wait for completion.

Changes:

Remove forceFlush handling from ss3, csi, osc, dcs, apc, esc_less_mouse, and esc_less_x10_mouse states — these now always call markPending() and return when data runs out
Retain forceFlush handling in esc and esc_recovery states where a lone ESC is genuinely ambiguous
Add inline comments explaining why each state no longer honors timeout-flushing

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Hona · 2026-03-16T00:33:34Z

+            // ESC[ already seen — unambiguously CSI. Wait for final byte
+            // or interruption by a new ESC (handled below). Don't
+            // timeout-flush; split sequences across reads are common on
+            // Windows Terminal with kitty keyboard.
+            this.markPending()
+            return


The maxPendingBytes overflow (64MB) is the hard safety net, but in practice any new input breaks it out — either a new ESC interrupts at line 759, or any byte in the final-byte range (0x40-0x7E) terminates the CSI. A secondary timeout would just reintroduce the race for a scenario that doesn't happen with real terminals.

          if (this.cursor >= bytes.length) {
-            if (!this.forceFlush) {
-              this.markPending()
-              return
-            }
-
-            this.emitOpaqueResponse("unknown", bytes.subarray(this.unitStart, this.cursor))
-            this.state = { tag: "ground" }
-            this.consumePrefix(this.cursor)
-            continue
+            // ESC[ already seen — unambiguously CSI. Wait for final byte
+            // or interruption by a new ESC (handled below). Don't
+            // timeout-flush; split sequences across reads are common on
+            // Windows Terminal with kitty keyboard.
+            this.markPending()
+            return


simonklee · 2026-03-16T21:54:32Z

I agree with the csi part, but I don't think its true for osc / dcs / apc (or ss3).

ESC[ already has a resync path for incomplete CSI: if a new ESC arrives, it flushes the partial CSI and restarts at the new escape. That makes it workable for split kitty sequences like ESC[118;5 + ;3u.
ESC], ESCP, and ESC_ do not have that recovery behavior. if we "keep waiting forever" it is unsafe because they are open-ended control strings. FOr example send \x1b]52;c;, wait past the 10ms timeout, then type abc or even \x1b[A. No key events are emitted, because the parser is still in osc and keeps treating those bytes as OSC payload until BEL / ESC\ or overflow.
I think this should be narrowed to csi rather than all framed escape states.

I think we can:

Only disable timeout-flush in csiinside csi.
Keep timeout flush for ss3, osc, dcs, apc

Stop the timer from looping for pending csi (bug in current pr), because a single partial sequence now creates a permanent wakeup loop until more bytes arrive

I can also try to clean this up for you tomorrow 😉

Hona · 2026-03-16T22:35:01Z

thanks @simonklee I've in theory actioned what you said if you can take another look
im kinda blind with a lot of this terminal stuff

simonklee · 2026-03-17T12:06:22Z

thanks @simonklee I've in theory actioned what you said if you can take another look im kinda blind with a lot of this terminal stuff

Thanks — i'm looking at this, but it's a bit of a rabbit hole. I'll try to clean up my patch later tonight.

Keep split CSI sequences resumable across timeout while flushing unsafe framed escape states. Also stop timed-out pending CSI from re-arming the parser wakeup loop until new bytes arrive.

Timed-out generic CSI prefixes are ambiguous, but reply families can be safely deferred when their protocol windows are known to be active. Add parser-level protocol context and explicit CSI sub-states so timeout deferral is driven by byte state + negotiated protocol state. Keep generic CSI conservative (flush on timeout) to prevent stale-prefix input capture, allow deferred reassembly for kitty keyboard, SGR mouse, private capability replies, pixel resolution responses, and explicit-width CPR only.

simonklee · 2026-03-17T20:43:34Z

thanks @simonklee I've in theory actioned what you said if you can take another look im kinda blind with a lot of this terminal stuff

Thanks — i'm looking at this, but it's a bit of a rabbit hole. I'll try to clean up my patch later tonight.

I'm going to have another look and do some more interactive testing with different setups before merging this tomorrow.

…o#819) Timed-out generic CSI prefixes are ambiguous, but reply families can be safely deferred when their protocol windows are known to be active. Add parser-level protocol context and explicit CSI sub-states so timeout deferral is driven by byte state + negotiated protocol state. Keep generic CSI conservative (flush on timeout) to prevent stale-prefix input capture, allow deferred reassembly for kitty keyboard, SGR mouse, private capability replies, pixel resolution responses, and explicit-width CPR only. Fixes anomalyco#818 --------- Co-authored-by: Simon Klee <hello@simonklee.dk>

Hona requested review from kommander, msmps and simonklee as code owners March 16, 2026 00:25

Copilot AI review requested due to automatic review settings March 16, 2026 00:25

Copilot started reviewing on behalf of Hona March 16, 2026 00:25 View session

Copilot AI reviewed Mar 16, 2026

View reviewed changes

Hona force-pushed the fix/csi-timeout-flush branch from e1521b2 to 71b5fc8 Compare March 16, 2026 00:37

This was referenced Mar 16, 2026

fix(opencode): image paste on Windows Terminal 1.25+ with kitty keyboard anomalyco/opencode#17674

Merged

fix: disable mouse tracking before restoring cooked mode in finalizeDestroy #802

Closed

Hona and others added 3 commits March 17, 2026 21:40

fix: don't timeout-flush unambiguous escape sequences split across reads

ad80a33

fix: narrow escape timeout recovery to CSI

03a20c0

Keep split CSI sequences resumable across timeout while flushing unsafe framed escape states. Also stop timed-out pending CSI from re-arming the parser wakeup loop until new bytes arrive.

simonklee force-pushed the fix/csi-timeout-flush branch from 1fba2e7 to 43ce950 Compare March 17, 2026 20:42

simonklee approved these changes Mar 18, 2026

View reviewed changes

simonklee merged commit eda42a6 into main Mar 18, 2026
23 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: don't timeout-flush unambiguous escape sequences split across reads#819

fix: don't timeout-flush unambiguous escape sequences split across reads#819
simonklee merged 3 commits intomainfrom
fix/csi-timeout-flush

Hona commented Mar 16, 2026

Uh oh!

pkg-pr-new Bot commented Mar 16, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Hona Mar 16, 2026

Uh oh!

simonklee commented Mar 16, 2026

Uh oh!

Hona commented Mar 16, 2026

Uh oh!

simonklee commented Mar 17, 2026

Uh oh!

simonklee commented Mar 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

Hona commented Mar 16, 2026

Summary

Uh oh!

pkg-pr-new Bot commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Hona Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

simonklee commented Mar 16, 2026

Uh oh!

Hona commented Mar 16, 2026

Uh oh!

simonklee commented Mar 17, 2026

Uh oh!

simonklee commented Mar 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

pkg-pr-new Bot commented Mar 16, 2026 •

edited

Loading