Ghostty: focus-gained handler re-arms mode 1004, causing a 42k writes/s feedback loop in an idle session

[MatCer]

Summary

In Ghostty, an idle jcode session burns 66% CPU in the client and 90-106% in Ghostty's renderer thread, purely because the window is focused. Empty session, no prompt typed, nothing streaming.

jcode issues ~42,000 write() syscalls per second, 61 bytes each, 2.5 MB/s into a 114x32 terminal. Unfocus the window and it drops to exactly 0. Refocus and it comes straight back.

Two behaviours form a loop:

1. jcode calls reapply_configured_terminal_modes() inside its Event::FocusGained handler, which re-issues ESC[?1004h (EnableFocusChange).
2. Ghostty answers any set of mode 1004 by reporting the current focus state. While focused that reply is CSI I, which crossterm decodes as Event::FocusGained.

jcode's response to a focus event generates another focus event. No timer is involved, which is why no rendering setting affects it.

Suggested labels: bug, priority: high, triage: reproducible, autonomous: clear.

Environment

• jcode v0.81.7 (358226c), prebuilt Linux x86_64 binary
• Ghostty 1.3.1
• Ubuntu, GNOME 46, Wayland (also reproduced on X11)
• crossterm 0.29.0 (Cargo.lock:1426-1428)
• Terminal 114x32

Reproduction

Open a Ghostty tab, run jcode, type nothing. Sample the client:

P=<jcode client pid>
W1=$(awk '/^syscw/{print $2}' /proc/$P/io); sleep 5
W2=$(awk '/^syscw/{print $2}' /proc/$P/io); echo $(( (W2-W1)/5 )) writes/s

Sample unfocused, then focused, then unfocused again.

window state	write() syscalls/s	jcode CPU
not focused	0	0%
focused	42,740 / 42,603 / 42,384	66-67%
not focused again	0	0%

Ghostty threads while focused: renderer 104-106%, io-reader 29%, io 25%. A Ghostty window running sleep 600 sits at 0%, so Ghostty alone does not spin.

Root cause

crates/jcode-tui/src/tui/app/local.rs:397:

Some(Ok(Event::FocusGained)) => {
    crate::tui::reapply_configured_terminal_modes();

That reaches reapply_terminal_modes_to (mod.rs:155-179), which re-issues the mode set with no rate limit, no dedup, and no check that the modes were ever lost:

writer.queue(EnableBracketedPaste)?;
if focus_change { writer.queue(EnableFocusChange)?; }   // ESC[?1004h

Same call at remote.rs:395 and remote.rs:772. The latter is in handle_terminal_event_while_disconnected, so a disconnected client spins too.

Event::FocusLost (local.rs:403) does not reapply. That asymmetry is why the bug is focus-gated.

Ghostty v1.3.1, src/termio/stream_handler.zig:755:

.focus_event => if (enabled) self.messageWriter(.{
    .focused = self.terminal.flags.focused,
}),

Setting mode 1004 emits the current focus state, with no check for whether the mode was already enabled. Re-arming an armed mode still produces a reply. This arrived in Ghostty PR #2196.

The cycle:

FocusGained (local.rs:397)
  -> reapply_configured_terminal_modes()   (local.rs:398)
  -> ESC[?1004h inside a 61-byte payload   (mod.rs:165)
  -> Ghostty replies CSI I                 (stream_handler.zig:755)
  -> crossterm decodes Event::FocusGained
  -> repeat

Unfocused, Ghostty replies CSI O, FocusLost does not reapply, and it stops after one hop.

The payload size matches:

$ printf '\033[?2004h\033[?1004h\033[?1000h\033[?1002h\033[?1003h\033[?1015h\033[?1006h\033[=7u' | wc -c
61

42,740 writes/s x 61 B = 2.6 MB/s, matching the measured 2.5 MB/s.

Reproduction without Ghostty

A pty.fork() harness running the real jcode binary, emulating one Ghostty behaviour and nothing else: on seeing b"\x1b[?1004h" from the slave, write back b"\x1b[I" for focused or b"\x1b[O" for unfocused. Dumb sink otherwise.

Same binary, same environment, 8 second runs, one byte of difference in the reply:

simulated state	bytes from jcode	ESC[?1004h observed
focused (reply ESC[I)	18,796,851 (2.35 MB/s)	308,110
unfocused (reply ESC[O)	1,999	1

Reproduced three times at 33,860/s, 38,396/s and 41,447/s. Any terminal that answers a 1004 mode-set with the current focus state triggers this, so Ghostty is not a necessary condition.

Harness source

#!/usr/bin/env python3
"""Usage: repro.py <focused:0|1> <seconds>"""
import os, pty, sys, time, select, signal, fcntl, termios, struct

SET_1004 = b"\x1b[?1004h"
FOCUSED = sys.argv[1] == "1"
DURATION = float(sys.argv[2])
REPLY = b"\x1b[I" if FOCUSED else b"\x1b[O"

pid, fd = pty.fork()
if pid == 0:
    env = dict(os.environ)
    env.update({
        "TERM": "xterm-ghostty",
        "TERM_PROGRAM": "ghostty",
        "GHOSTTY_RESOURCES_DIR": "/usr/share/ghostty",
        "COLUMNS": "114", "LINES": "32",
    })
    os.execvpe("jcode", ["jcode"], env)

fcntl.ioctl(fd, termios.TIOCSWINSZ, struct.pack("HHHH", 32, 114, 0, 0))

start = time.time()
total_bytes = reads = replies = 0
buf = b""
while time.time() - start < DURATION:
    r, _, _ = select.select([fd], [], [], 0.2)
    if not r:
        continue
    try:
        data = os.read(fd, 65536)
    except OSError:
        break
    if not data:
        break
    total_bytes += len(data)
    reads += 1
    buf = (buf + data)[-4096:]
    n = buf.count(SET_1004)
    if n:
        buf = buf.replace(SET_1004, b"")
        for _ in range(n):
            os.write(fd, REPLY)
            replies += 1

elapsed = time.time() - start
os.kill(pid, signal.SIGKILL)
os.waitpid(pid, 0)
print(f"focused={FOCUSED} elapsed={elapsed:.1f}s")
print(f"  bytes from jcode : {total_bytes:,} ({total_bytes/elapsed/1e6:.2f} MB/s)")
print(f"  ESC[?1004h seen  : {replies:,} ({replies/elapsed:.0f}/s)")

Why GNOME Terminal is unaffected

VTE reports focus transitions only, never in response to the mode being set, so nothing answers and no loop forms. That was the original clue: the same session in GNOME Terminal does not spin.

jcode has no terminal-specific branch here. perf.rs:208 sets enable_focus_change = true unconditionally, and only perf.rs:234 (WSL plus Windows Terminal) disables it. detect_terminal does recognise Ghostty, but that only feeds fragile_glyph_cache.

Ruled out by measurement

Each of these was changed on the live affected session with no effect:

hypothesis	result
display.redraw_fps 60 -> 30 -> 10	~42k writes/s in all three
display.performance = reduced, minimal	unchanged
display.latex_rendering image -> text	unchanged
display.mouse_capture = false	43,486 writes/s
display.prompt_entry_animation = false	42,320 writes/s
display.pin_todos = false	42,274 writes/s
display.prompt_preview = false	42,680 writes/s
X11 versus Wayland	unchanged
disk logging	log grew 0 KB/s during the spin

The redraw scheduler cannot cause this. redraw_schedule.rs:16-20 floors intervals at 250 ms and 5 s, and redraw_schedule.rs:428 returns REDRAW_DEEP_IDLE when !client_focused, so focus makes the schedule slower. The fastest scheduler path is 4 draws/s, three orders of magnitude below what I measured.

These writes never pass through ratatui. They go out through crossterm's queue/flush in mod.rs:155-179, so client:draw-stats cannot see them.

Related issues

• Perf: jcode CPU/battery audit — /proc scan + per-frame disk reads fixed; profile TUI streaming render & self-dev build/reload (for @Fable5) #392 (closed) diagnosed streaming-tail markdown re-render. Different cause: this session is empty and nothing streams. I misattributed this bug to Perf: jcode CPU/battery audit — /proc scan + per-frame disk reads fixed; profile TUI streaming render & self-dev build/reload (for @Fable5) #392 before measuring an empty session.
• RunningTool status skips the spinner fast path and forces a full-frame flush every tick #1071 (closed, fixed) was RunningTool forcing a full-frame flush at roughly 1/s. Different mechanism and four orders of magnitude apart.
• TUI input and scrolling degrade in long sessions due to render-path work and mixed terminal readers #540 (open) covers input latency from render-path work. Related area, different mechanism.

Nothing open covers focus-triggered mode re-arming.

Fix

reapply_terminal_modes_to already takes a focus_change flag (mod.rs:159). The three focus-path callers should not re-arm the one mode whose reply re-triggers them. Non-focus callers keep re-arming it, since the defensive re-arm matters after an external program may have cleared the modes. Focus reporting is still enabled once at startup, so nothing changes functionally.

A patch doing this is on a branch, since this repo does not accept external pull requests: MatCer@74ae3a8

Three call sites pass false, plus a regression test on the emitted bytes. Measured on the same machine:

binary	simulated state	ESC[?1004h loops in 8s
v0.81.7	focused	331,577 (41,447/s), 20.2 MB
patched	focused	1, 3.3 KB
patched	unfocused	1, 2.2 KB

The remaining occurrence is the normal startup mode-set.

Impact

Any jcode user in Ghostty, or any terminal that reports focus state on mode-set, pays about one CPU core in jcode plus another in the terminal renderer for as long as the window is focused. I found this because the machine got hot whenever the jcode tab was in front. The workarounds are keeping the tab unfocused or using a different terminal.

[potb]

Same thing on macOS, so it is not Linux-specific.

Apple M5 (Mac17,2), macOS 26.6.2, Ghostty 1.3.1, jcode v0.84.0 (57d5878), terminal 186x33.

Focusing and unfocusing the window, measured with top -l 2:

window state	ghostty	jcode
unfocused	9.9%	0.9%
focused	135.9%	30.4%

Idle session, nothing streaming. Fans spin up within seconds of the window coming to the front and settle as soon as I click away.

I found it the same way, hunting down why the laptop was hot. Three jcode windows open, and the hot one was always whichever had focus, which is what led me here.

[ianalitis]

Independently verified local fix (2682f0668)

Focus-event mode rearming (#1184)

Source baseline: e7e58c603, macOS arm64, 2026-09-08.
Duplicate check: #1184 is open, including
independent Linux and macOS reports. Public master
4e85d4423cfd248236044564aa8e4d48ce0ae473 still contains the implicated writer.
No other branch's patch was imported.

Reproduction

Add terminal_mode_tests::reapply_does_not_request_another_focus_report from this
patch to the baseline (using its original four-argument writer signature).
Run cargo test --profile selfdev -p jcode-tui --lib terminal_mode_tests.
Observed: 2 passed, 1 failed because the production writer emits ESC[?1004h.
That command requests a fresh focus report on terminals such as Ghostty.
Local, connected-remote and disconnected-remote FocusGained handlers all call
reapply_configured_terminal_modes, which calls this writer. Re-emitting mode
1004 therefore creates another event instead of leaving the TUI idle.

Fix

Remove focus-report enabling and its now-unused argument from the shared
focus-restoration writer. Keep bracketed paste, configured mouse capture and
Kitty's set-form keyboard restoration. Do not disable focus reporting.
Startup and external-editor resume still enable focus reporting separately.
No timer, debounce, new state, configuration option or dependency is needed.

Observed local verification

• Baseline selfdev test task 7086039lft: 2 passed, 1 expected regression failure.
• Fixed task 759637u11x: all 3 terminal-mode tests passed, including the four
  mouse/keyboard preference combinations and absence of focus enable/disable.
• cargo test --profile selfdev -p jcode-tui --lib client_focus: passed.
• cargo clippy --profile selfdev -p jcode-tui --lib -- -D warnings: passed.
• Scoped rustfmt and diff review: startup/editor paths untouched, all three
  focus handlers still update focus state and use the corrected shared writer.
• Existing test-linker large __eh_frame warning remains, not suppressed.

These are production-writer and focus-state library checks, not a live Ghostty
benchmark, PTY end-to-end run, or deployed-daemon acceptance. No CPU percentage
improvement is claimed. No visible layout changed. The interface contract is
unchanged focus/mouse/paste/keyboard behavior without generating focus feedback.

Patch below contains only this issue's source/test changes. It applies cleanly (git apply --check) to the affected files at upstream 4e85d4423cfd248236044564aa8e4d48ce0ae473. This is not a full build/test on upstream, and no mixed local history is being proposed.

Scoped patch

diff --git a/crates/jcode-tui/src/tui/mod.rs b/crates/jcode-tui/src/tui/mod.rs
index 8d1ca2870..80ffc919c 100644
--- a/crates/jcode-tui/src/tui/mod.rs
+++ b/crates/jcode-tui/src/tui/mod.rs
@@ -148,23 +148,21 @@ pub fn disable_keyboard_enhancement() {
     );
 }
 
-/// Reassert terminal modes that terminals may clear while the TUI remains alive.
+/// Reassert input modes when the TUI receives a focus report.
 ///
-/// These commands are idempotent. Kitty keyboard enhancement uses its `set`
+/// Do not re-enable focus reporting here: terminals such as Ghostty answer that
+/// command with another focus report, causing a feedback loop. Startup and editor
+/// resume enable focus reporting separately. Kitty keyboard enhancement uses its `set`
 /// form rather than the stack-based `push`, keeping the shutdown pop balanced.
 pub(crate) fn reapply_terminal_modes_to(
     writer: &mut impl std::io::Write,
     mouse_capture: bool,
     keyboard_enhanced: bool,
-    focus_change: bool,
 ) -> std::io::Result<()> {
     use crossterm::QueueableCommand;
-    use crossterm::event::{EnableBracketedPaste, EnableFocusChange, EnableMouseCapture};
+    use crossterm::event::{EnableBracketedPaste, EnableMouseCapture};
 
     writer.queue(EnableBracketedPaste)?;
-    if focus_change {
-        writer.queue(EnableFocusChange)?;
-    }
     if mouse_capture {
         writer.queue(EnableMouseCapture)?;
         // Crossterm toggles Win32 console mouse input on Windows, but ConPTY
@@ -184,7 +182,6 @@ pub(crate) fn reapply_configured_terminal_modes() {
         &mut std::io::stdout(),
         policy.enable_mouse_capture,
         policy.enable_keyboard_enhancement,
-        policy.enable_focus_change,
     ) {
         crate::logging::warn(&format!("failed to reapply terminal modes: {error}"));
     }
@@ -194,13 +191,30 @@ pub(crate) fn reapply_configured_terminal_modes() {
 mod terminal_mode_tests {
     use super::reapply_terminal_modes_to;
 
+    #[test]
+    fn reapply_does_not_request_another_focus_report() {
+        for mouse_capture in [false, true] {
+            for keyboard_enhanced in [false, true] {
+                let mut output = Vec::new();
+                reapply_terminal_modes_to(&mut output, mouse_capture, keyboard_enhanced).unwrap();
+                let output = String::from_utf8(output).unwrap();
+                assert!(output.contains("\x1b[?2004h"));
+                assert!(
+                    !output.contains("\x1b[?1004h"),
+                    "rearming focus reports makes Ghostty reply with another FocusGained"
+                );
+                assert!(!output.contains("\x1b[?1004l"), "keep reporting enabled");
+            }
+        }
+    }
+
     #[test]
     fn reapply_omits_mouse_sequences_when_capture_is_disabled() {
         let mut output = Vec::new();
-        reapply_terminal_modes_to(&mut output, false, true, true).unwrap();
+        reapply_terminal_modes_to(&mut output, false, true).unwrap();
 
         let output = String::from_utf8(output).unwrap();
-        assert!(output.starts_with("\x1b[?2004h\x1b[?1004h"));
+        assert!(output.starts_with("\x1b[?2004h"));
         assert!(!output.contains("\x1b[?1000h"));
         assert!(output.contains("\x1b[="));
     }
@@ -208,11 +222,11 @@ mod terminal_mode_tests {
     #[test]
     fn reapply_emits_configured_idempotent_modes_without_keyboard_push() {
         let mut output = Vec::new();
-        reapply_terminal_modes_to(&mut output, true, true, true).unwrap();
+        reapply_terminal_modes_to(&mut output, true, true).unwrap();
 
         let output = String::from_utf8(output).unwrap();
         assert!(output.contains("\x1b[?2004h"));
-        assert!(output.contains("\x1b[?1004h"));
+        assert!(!output.contains("\x1b[?1004h"));
         assert!(output.contains("\x1b[?1000h"));
         assert!(output.contains("\x1b[="), "must set Kitty keyboard flags");
         assert!(

[MatCer]

Same root cause on my end.

I had a version that kept EnableFocusChange in the writer behind a rearm_focus_reporting: bool. Yours is better. All three callers are focus handlers, so the flag was never true.

Checked what removal costs. Nothing here: RIS wouldn't be recovered by re-arming on focus either, the ConPTY workaround is mouse-only and stays, and startup plus editor resume enable 1004 explicitly. A real resume trigger would want its own function, not a flag on this one.

Switched my branch to your shape: MatCer/jcode@d311d21.

Two deltas. The writer tests are #[cfg(all(test, unix))], since crossterm's EnableMouseCapture goes through the console API on Windows and byte assertions fail without a console. And they assert ESC[?1004l is absent too, so a later patch that disables reporting instead of leaving it alone also fails.

[1jehuang]

Thanks for the report. The focus handler no longer rearms focus reporting on focus events.

Proposed fix: #1218, commit 38f7967. Four focused TUI tests passed. A live terminal CPU benchmark was not run.

The PR remains a draft pending clean-branch CI and review. It documents the local build limitations. This issue remains open until the fix is merged and verified.

---

— Jcode agent (automated triage), on behalf of @1jehuang