Focus reporting (DECSET ?1004) is not restored on exit - [I/[O leak into the parent shell #4362

Describe the bug

Copilot CLI enables xterm focus reporting (DECSET ?1004) and does not disable it when the process exits abnormally (crash, or abort during an operation). The terminal keeps emitting focus events after Copilot is gone, and with nothing left to consume them they land in the parent shell as literal input.

On Windows Terminal with PowerShell the effect is immediately disruptive. Every focus change injects [I (focus gained, CSI I) or [O (focus lost, CSI O) at the prompt, and PowerShell parses [I as the opening of a type literal, so the shell errors:

D:\Git> [I[O[I
ParserError:
Line |
   1 |  [I[O[I
     |         ~
     | Missing ] at end of attribute or type literal.

One [I/[O pair arrives per alt-tab or window click, so the prompt stays unusable until the mode is reset by hand.

The confirming symptom is a Copilot TUI still painted on screen with no copilot or node process running — the terminal has been left in TUI-oriented input mode by a process that has already exited.

Affected version

GitHub Copilot CLI 1.0.78

Steps to reproduce the behavior

1. Start copilot in Windows Terminal with PowerShell as the shell.
2. Cause the process to terminate abnormally. In my case the session died on its own (see Additional context); taskkill /f /im copilot.exe produces the same terminal state.
3. At the recovered PowerShell prompt, click to another window and back.
4. [I / [O appear at the prompt. Pressing Enter produces the ParserError above.

Manual recovery, for anyone who finds this issue while stuck:

[Console]::Write("`e[?1004l")

Expected behavior

Copilot restores the terminal modes it enabled — at minimum focus reporting (?1004) and mouse tracking (?1000/?1002/?1003/?1006) — on every exit path including abnormal ones, leaving the parent shell as it was found.

Two changes would each help, independently:

1. Move the mode-restore into a handler that also runs on abnormal termination (panic/abort/signal), not only on clean shutdown.
2. Add a setting to opt out of focus reporting, in the same spirit as the existing terminalProgress, whose own documentation says "Set to false to suppress these escape sequences on terminals that render them as visible artifacts." mouse is a second precedent. There is currently no equivalent for ?1004, so a user hitting this has no supported way to avoid it.

The second is valuable even if the first lands, since it also helps terminals and multiplexers that mishandle focus events while Copilot is running normally.

Additional context

Related issues:

• Mouse text selection broken in Windows Terminal after exiting Copilot session #2332 — same failure class: terminal left in a bad mode after exiting a Copilot session (mouse selection rather than focus reporting).
• Enhance copilot to enable reporting focus, respond to entering and exiting focus #459 — the feature request that introduced focus reporting.
• This is a known cross-tool TUI hazard rather than something specific to Copilot. Claude Code has the consuming-side equivalent ([BUG] When terminal sends Focus In/Out events (DECSET 1004), [ I / [ O appear in input. Expected: handled/ignored. anthropics/claude-code#11391 and #18363, closed as duplicates of #18208), and vim removed mode 1004 from its XM termcap over the same class of problem.

What terminated the session — possibly a separate issue, happy to split it out. The session log ends with repeated bridge-ack timeouts, one in the same second as a subagent launch:

12:49:14.535Z [WARNING] [rust:copilot_runtime::interop::bridge_backed_seam] timed out waiting for bridge event ack {"event_kind":"event","timeout_ms":30000}
12:51:54.590Z [INFO]    Completing 1 orphaned tool calls.
12:53:59.317Z [WARNING] [rust:copilot_runtime::interop::bridge_backed_seam] timed out waiting for bridge event ack {"event_kind":"event","timeout_ms":30000}
12:53:59.553Z [INFO]    SessionAgentExecutor.execute() called for "rubber-duck" (toolCallId=…)
12:54:03.747Z [INFO]    --- End of group ---
                        <process gone>

Fourteen such bridge-ack timeouts occurred in that one session over a day. This may relate to #4026 and #2543. The terminal-mode leak is independent of the cause of death, though — any abnormal exit produces it.

Environment:

• OS: Windows 11 Enterprise, build 10.0.26200
• CPU architecture: x86_64 (AMD64)
• Terminal emulator: Windows Terminal
• Shell: PowerShell 7.6.4 (pwsh)
• Node: v24.18.1
• Relevant settings: mouse: false, autoUpdate: false

Happy to provide fuller logs via --log-level debug --log-file if useful.