Skip to content

Shift + Win opens Windows Start after a Win + Shift hotkey from another app; Win afterwards can leave a hidden Search window holding focus #2569

Open

Description

@nroj95

Describe the bug

Two related problems with "Shift + Win opens: Windows Start Menu" (the default):

  1. After a hotkey that uses Win + Shift from a tool like AutoHotkey, releasing the keys opens the Windows Start menu. Hotkey tools consume the hotkey's own key and send a "mask" key before Win is released, so the release doesn't count as a lone Win tap. Windows' own Start respects this; Open-Shell's Shift + Win handling seems not to. Mask keys vkE8 (AutoHotkey's default), vkFF, vk07 and vk88 all gave the same result.

  2. Closing the Open-Shell menu after that can give focus to a cloaked SearchHost.exe "Search" window (class Windows.UI.Core.CoreWindow), so nothing visible has focus. While it holds the foreground, Windows refused every attempt by an AutoHotkey script to activate another window (SetForegroundWindow, SwitchToThisWindow, AttachThreadInput and more), until a click or Alt + Tab.

Area of issue

Start menu

To reproduce

Part 1:

  1. Run this AutoHotkey v2 script: #+Backspace::return
  2. Press Win + Shift + Backspace and release.
  3. The Windows Start menu opens.

Part 2 (reproduces by hand with no AutoHotkey script running):

  1. Press Shift + Win: the Windows Start menu opens.
  2. Press Win: the Open-Shell menu opens.
  3. Press Win again: the Open-Shell menu closes.
  4. The foreground window is now the cloaked SearchHost.exe "Search" window.

Expected behavior

Part 1: nothing opens, as on the same PC without Open-Shell, and as after Windows' own shortcuts such as Win + Shift + S or Win + Shift + Left.
Part 2: focus returns to the window that was active before step 1.

Open-Shell version

4.4.198

Windows version

Windows 11 Pro 26H2 (build 26300.9711)

Additional context

Workaround: setting "Shift + Win opens" to Nothing in Controls avoids both, since both start with Shift + Win opening Windows Start.

Possible fixes: for part 1, treat a key event between Win down and Win up, including an injected mask key, as "another key was pressed", as Windows' Start does. For part 2, make sure focus doesn't land on a cloaked window when the menu closes. I couldn't tell whether Open-Shell or Windows picks the window that gets focus back.

AutoHotkey 2.0.26 was used for part 1.

Foreground windows logged during part 2, polled every 50 ms:

06:16:11 firefox.exe     MozillaWindowClass          cloaked=no   (start)
06:16:14 SearchHost.exe  Windows.UI.Core.CoreWindow  cloaked=no   (Shift + Win)
06:16:16 explorer.exe    OpenShell.CMenuContainer    cloaked=no   (Win)
06:16:18 SearchHost.exe  Windows.UI.Core.CoreWindow  cloaked=yes  (Win)
06:16:30 claude.exe      Chrome_WidgetWin_1          cloaked=no   (mouse click)

Activity

  1. added
    BugSomething isn't working right.
    on Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugSomething isn't working right.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions