copilot cli drops enter and other key events when the terminal pane is unfocused

describe the bug

i maintain herdr, an agent multiplexer with roughly 20k stars and hundreds of thousands of downloads. herdr supports copilot cli alongside other agent harnesses and lets users automate any pane through its pty, including panes that are not currently focused.

copilot cli enables terminal focus reporting with csi ? 1004 h. after it receives focus-out (csi o), its main input box ignores normal key events written to the pty. pasted text may still appear, but enter is discarded, so an automation request looks delivered without ever being submitted. after focus-in (csi i), the same enter byte works immediately.

this breaks automation and orchestration tools that intentionally address background panes. herdr's report and investigation are here:

https://github.com/ogulcancelik/herdr/issues/1698

affected version

1.0.69
1.0.73
1.0.74-0

steps to reproduce with herdr

1. create a tab with two split panes.
2. start copilot cli in the right pane:

herdr agent start copilot-test --kind copilot --pane <right-pane>

3. focus the left pane so copilot is an unfocused split sibling.
4. send a prompt:

herdr agent prompt <right-pane> "reply with exactly ok"

5. herdr accepts the request, and the text may appear in copilot's input box, but enter is ignored. copilot remains idle and never responds.
6. repeated enter through agent send-keys also does nothing:

herdr agent send-keys <right-pane> enter

7. focus the copilot pane and send enter again:

herdr agent focus <right-pane>
herdr agent send-keys <right-pane> enter

8. the existing prompt submits immediately and copilot responds.

using agent prompt --wait makes the failure observable as agent_prompt_stalled, but it cannot make copilot process enter.

independent reproduction with tmux

this control experiment removes herdr from the input path.

1. start copilot cli inside a tmux pane and wait for its main input box.
2. enable focus events and send focus-out, text, and enter:

tmux set -g focus-events on
tmux send-keys -t <pane> -l $'\e[O'
tmux send-keys -t <pane> -l 'reply with exactly ok'
tmux send-keys -t <pane> enter

3. the text appears, but enter does nothing and no turn starts.
4. send focus-in followed by enter:

tmux send-keys -t <pane> -l $'\e[I'
tmux send-keys -t <pane> enter

5. the prompt submits immediately and copilot responds.

expected behavior

terminal focus should control visual focus behavior such as cursor rendering and notifications. it should not prevent the application from processing valid input already delivered to its pty.

programmatic input addressed to an unfocused pane should behave the same as input addressed to a focused pane.

additional context

this reproduces outside herdr with tmux send-keys, so it is not caused by herdr's pty delivery. the shipped bundle also shows that the main input handler returns early while terminal focus is false unless the event is paste, backspace, or delete.

the folder-trust dialog still accepts enter while unfocused, so the gate appears specific to the main input component.

the closest existing report is #4180, but that issue describes broader automated pty input failure and states that sending focus-in did not help. this report is narrower: focus-out deterministically disables normal key handling, and focus-in restores it.

tested independently with tmux 3.7b on linux x86_64. the original herdr reproduction used macos, ghostty, and herdr 0.7.5.

Beginne damit, die focus-out-, text- und enter-Sequenz mit tmux 3.7b zu reproduzieren, und vergleiche sie dann mit focus-in gefolgt von enter. Untersuche den main input handler des ausgelieferten Bundles, insbesondere den frühen Rücksprung, wenn der Terminalfokus false ist, und verifiziere, dass normale pty-Tastenereignisse den Prompt absenden, während das Verhalten des visuellen Fokus intakt bleibt.