/side isnt respecting ctrl+/ in Git Bash Windows

Some diagnosis from the source: codex already anticipates the usual Ctrl+/ ambiguity — the dispatch accepts both ctrl-/ and the legacy ctrl-7 encoding (terminals classically send byte 0x1F for Ctrl+/, which the ANSI parser decodes as Ctrl+7): https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/tui/src/app/input.rs#L312-L323. So the failure in Git Bash is at the decode layer, not the keymap.

Git Bash runs codex under mintty→ConPTY, where input arrives as Windows console key events rather than ANSI bytes. On that path 0x1F tends to surface as a control character with no clean Ctrl+'/'‑or‑Ctrl+'7' identity — commonly Ctrl+'_' or a bare Char('\u{1F}') — which matches neither accepted binding, so the chord silently does nothing (while Windows Terminal, sending proper VK data, works).

Two fixes: (1) broaden the alias set at the same dispatch site to include Ctrl+'_'/Char('\u{1F}'); (2) more generally, a /keys debug view that prints the decoded KeyEvent would make this whole class of "terminal X eats chord Y" report self-diagnosable. Workaround meanwhile: bind an alternative via [tui.keymap.global] toggle_side_conversation = ["alt-s"] (any chord Git Bash delivers cleanly).