<space> key for staging does not work when running lazygit inside Neovim on Windows (regression between 0.57.0 and 0.60.0)

[g405h3n]

Environment

Component	Version
OS	Windows 10 (Version 22H2, Build 19045)
Neovim	0.12.0
lazygit (broken)	0.58.0, 0.59.0, 0.60.0
lazygit (working)	0.57.0
Terminal	Bash (Git Bash)

Problem

When launching lazygit from inside Neovim's :terminal on Windows, the <space> key appears to have no effect for staging files. The file briefly stages and then immediately unstages (i.e., the keypress is detected twice), making it look as though the key was ignored.

This is likely related to #5344 (Keys are detected twice), which reports the same double-detection behavior for all keys since 0.58.0 on Windows.

This does not occur when:

• Running lazygit (either 0.58.0, or 0.59.0, or 0.60.0) directly in Bash (outside Neovim) on Windows — ✅ works
• Using lazygit 0.57.0 inside Neovim on Windows — ✅ works

Steps to Reproduce

1. On Windows, open a terminal (e.g., Git Bash).
2. Run nvim --clean (no plugins, no config).
3. Inside Neovim, run :terminal.
4. Press i to enter terminal mode.
5. Run lazygit in a repo with unstaged changes.
6. Navigate to a file and press <space> to stage it.
7. Expected: File is staged.
8. Actual: The file appears to stay unstaged. It briefly stages then immediately unstages (double-detection), giving the appearance that <space> had no effect.

Investigation & Findings

I ran several tests:

Test	Result	Implication
cat -v inside Neovim :terminal then press <space>	Normal space (ASCII 0x20)	Neovim is not sending CSI-u encoded <space> (^[[32u). The correct byte is delivered.
tmap <Space> <Cmd>call chansend(b:terminal_job_id, " ")<CR>	Still broken	Even sending raw ASCII 0x20 directly to the PTY via chansend does not fix it.
nvim --clean → :terminal → lazygit	Still broken	No plugin interference. This is a bare Neovim + lazygit issue.
Downgrade lazygit to 0.57.0	✅ Fixed	Confirms the regression was introduced in lazygit 0.58.0 (reproducible on 0.58.0, 0.59.0, and 0.60.0).

• The issue is not Neovim sending wrong key encoding (CSI-u / Kitty protocol) — Neovim 0.12 correctly sends plain ASCII 0x20.
• The issue is not caused by Neovim plugins or config.
• The issue is a regression introduced in lazygit 0.58.0 (reproducible on 0.58.0, 0.59.0, and 0.60.0), where lazygit (via tcell/gocui) detects each keypress twice when running under Neovim's ConPTY on Windows. For <space>, this causes a stage→unstage cycle that appears as a no-op. See also #5344.

Workaround

Downgrade lazygit to 0.57.0.

[stefanhaller]

I tried this with the current lazygit master and neovim 0.12, and couldn't reproduce it. I'm using Win 11, not 10, that's the only difference I can see.

Do you see this only with space, or with all keys that you press, like in #5344?

[g405h3n]

I reproduced it with other keys such as <k> and <j> as well, with Windows 10 + Neovim 0.12 + lazygit 0.60.0 . For example, I navigated around panel [2] Files of lazygit, and cursor moved two lines each time I pressed <k>/<j>.

[stefanhaller]

Thanks. In that case it does sound like exactly the same as #5344, and you can mark this one as answered.