Desktop (Windows): Ctrl+L sometimes fails to restore composer focus (after accepting prompts or changing reasoning effort)

Description

In OpenCode Desktop on Windows, the composer sometimes ends up without keyboard focus, and pressing Ctrl+L — which is supposed to run the input.focus command and return focus to the composer — does nothing in those states.

I have hit this most often:

• after accepting a permission/tool prompt, and
• after changing the model's reasoning effort.

In both cases the composer stays unfocused and repeated presses of Ctrl+L do not restore it. The only recovery that works is clicking directly into the input field.

Related reports:

• #44243 — my feature request that Escape focus the prompt input field from anywhere
• #30887 — my earlier request for the same Esc-to-focus behavior, closed as not planned
• #29999 — dialogs keeping keyboard focus when a question prompt appears

Steps to reproduce

1. Open OpenCode Desktop on Windows and start an agent session.
2. When a permission/tool prompt appears, accept it (or change the model's reasoning effort mid-session).
3. Try to type into the composer; it does not have focus.
4. Press Ctrl+L one or more times.
5. Observe that the composer still does not receive focus.

Expected behavior

Ctrl+L always restores focus to the composer via the input.focus command, regardless of what had focus previously.

Actual behavior

After certain interactions (prompt acceptance, reasoning-effort change), Ctrl+L has no effect and only a mouse click into the composer restores focus.

Environment

• App: OpenCode Desktop 1.18.21
• OS: Microsoft Windows 11 Education, 25H2, build 26200.8875

Notes for maintainers

I could not isolate the exact state that breaks the keybind; it is intermittent rather than tied to every prompt acceptance. If there is debug output or a reproduction mode that would help narrow down when input.focus silently no-ops, I am happy to gather it.