WezTerm freezes after keyboard repeat

[jonathanslenders]

What Operating System(s) are you seeing this problem on?

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20240811-112922-0ac1e948

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

When holding down any key for a few seconds until it repeats, after releasing the key, the terminal becomes completely unresponsive for further key presses, except for control-key combinations. Resizing and mouse support remains functional, only typing is blocked.

I didn't had the issue until I upgraded today, I can't recall the previous version I had installed. It does not happen with any other terminal emulator.

To Reproduce

Hold down any key, like 'a' until it repeats. Release the key. Typing no longer works.

Configuration

wezterm.lua is empty.

Expected Behavior

No response

Logs

Debug Overlay wezterm version: 20240811-112922-0ac1e948 aarch64-apple-darwin Window Environment: macOS 14.6.1 (23G93) Lua Version: Lua 5.4 OpenGL: Apple M1 Pro 4.1 Metal - 88.1 Enter lua statements or expressions and hit Enter. Press ESC or CTRL-D to exit

Anything else?

When it happens, typing in other tab pages or the debug overlay is not possible. Opening the debug overlay using ctrl-shift-l works fine. Typing in a new window is also no issue.

[aaronmcadam]

I'm seeing this too. I hoped increasing the key repeat rate or reducing the delay until repeat would help, but it didn't.

[aaronmcadam]

The following things have triggered the issue for me:

• Vim diw text motion.
• Vim caw text motion.
• Vim w visual motion to select words.
• Vim j to jump down a line.
• Vim j to the bottom of the file fails whenever I hold down the key.

[dteoh]

I am also experiencing this issue. At first I thought it was something to do with Neovim (all keyboard input just dies once I go into a nvim-tree buffer), but now I see that just holding down one key in the shell also causes input to die. I can get input working again by using IME to switch to another language and back.

[steelcolosus]

I have the same problem but only on my laptop, on my work laptop, everything works great. Both are Macs and the only difference is the Python version:

• work: python=3.10.8
• personal: python=3.12

once I changed my laptop to Python 3.10.8 everything works

[norayesnir]

Same issue here. especially when i hold vim motions

[ckoehler]

Wow same issue! It seems to have started after updating to MacOS 15 from MacOS 14.

Deleting newer versions of Python from Homebrew didn't make a difference. Using the nightly doesn't fix it.

I thought maybe Karabiner Elements may be responsible, but disabling it also makes no difference.

Tried building from source, and same issue (somewhat expected since nightly didn't fix it).

As OP, running it without config with -n also has this, so it's not my config, but could be default config.

Hm this isn't happening on my other laptop which is also running MacOS 15; both machines are set up with nix-darwin, so setup is fairly similar...

I removed the nix config unique to the problem laptop, and it still happens, so those things all seem unrelated. Hmm.

[ckoehler]

Alright this makes no sense to me, but I've tried to trace system calls to debug this (from https://stackoverflow.com/questions/31045575/how-to-trace-system-calls-of-a-program-in-mac-os-x).

I started with sudo dtruss wezterm -n from the normal Mac Terminal app, which just froze, and then sudo ktrace trace -S -f C3 -c wezterm -n. The problem didn't occur during the trace, and looks to have fixed itself when I run it normally again, too. 🤷‍♂

Edit: thinking about this, I think I also restarted my Macbook after stuff froze with the dtruss call, so maybe a simple restart fixed this?

Edit2: blame my faulty memory. One of the apps I have as part of work is Wireshark, which with Homebrew installs Python. When I was debugging, I deleted Wireshark and all its deps, and later re-installed them completely (nix-darwin does this with the Homebrew integration). That could have made a difference (despite manually just removing all the Homebrew Python versions didn't fix it). Maybe this helps someone.

[sqrt0b1000]

Possible Workaround

WezTerm version

wezterm 20250424-220737-0f1c4a7f

To Reproduce

Hold down any key, like 'a' until it repeats. Release the key. Typing no longer works.

Expected Behavior

Window not freezes keyboard.

Workaround

The bug still exists in the latest nightly build: is there any way to free the keyboard, except starting a new window?

However, disabling the key repetition on OS level mitigates to freeze the keyboard accidentally.

As a consequence holding down a key, does no longer work, e.g., scrolling…

Idea for workaround

The idea for the workaround was taken from aaronmcadam see:

I'm seeing this too. I hoped increasing the key repeat rate or reducing the delay until repeat would help, but it didn't.

Anything else?

This seems to be an macOS specific bug. I am not sure what the program receives when a key is hold down, which disables any further keyboard input… I assume the release event might no the handled, which leads to this bug?

Logs

wezterm --config debug_key_events=true

Key a pressed until the second character appears. Then the key is released:

$ wezterm --config debug_key_events=true
18:19:32.467  INFO   wezterm_gui::termwindow::keyevent > key_event RawKeyEvent { key: Char('a'), modifiers: NONE, leds: (empty), phys_code: Some(A), raw_code: 0, repeat_count: 1, key_is_down: true, handled: Handled(false) }
18:19:32.468  INFO   wezterm_gui::termwindow           > DeadKeyStatus now: None
18:19:32.469  INFO   wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: Char('a'), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: true, raw: None }
18:19:32.469  INFO   wezterm_gui::termwindow::keyevent > send to pane DOWN key=Char('a') mods=NONE
18:19:32.469  INFO   wezterm_term::terminalstate::keyboard > key_down: sending "a", Char('a') NONE
18:19:32.469  INFO   wezterm_gui::termwindow               > DeadKeyStatus now: None
18:19:32.961  INFO   wezterm_gui::termwindow::keyevent     > key_event RawKeyEvent { key: Char('a'), modifiers: NONE, leds: (empty), phys_code: Some(A), raw_code: 0, repeat_count: 1, key_is_down: true, handled: Handled(false) }
18:19:32.962  INFO   wezterm_gui::termwindow::keyevent     > key_event KeyEvent { key: Char('a'), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: true, raw: None }
18:19:32.962  INFO   wezterm_gui::termwindow::keyevent     > send to pane DOWN key=Char('a') mods=NONE
18:19:32.962  INFO   wezterm_term::terminalstate::keyboard > key_down: sending "a", Char('a') NONE
18:19:33.265  INFO   wezterm_gui::termwindow::keyevent     > key_event RawKeyEvent { key: Char('a'), modifiers: NONE, leds: (empty), phys_code: Some(A), raw_code: 0, repeat_count: 1, key_is_down: false, handled: Handled(false) }
18:19:33.266  INFO   wezterm_gui::termwindow::keyevent     > key_event KeyEvent { key: Char('a'), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: false, raw: Some(RawKeyEvent { key: Char('a'), modifiers: NONE, leds: (empty), phys_code: Some(A), raw_code: 0, repeat_count: 1, key_is_down: false, handled: Handled(false) }) }
18:19:33.266  INFO   wezterm_gui::termwindow::keyevent     > send to pane UP key=Char('a') mods=NONE
>> Input: CMD-Q
18:21:22.378  INFO   wezterm_gui::termwindow               > QuitApplication over here (window)
´´´

Any typing afterwards does not produce any output in the logs. CMD-Q command still works.

[dancrossnyc]

I'm also seeing this, on macOS 15.5. Running with debugging, I can see that key events are still generated (and seen by WezTerm) but do not render, etc.