Originally created by @Keshav13142 on GitHub (Aug 1, 2023).
Describe the bug
If I try to close a floating window using the wkhd shortcut I assigned to komorebic close, the window behind it gets closed even though the focus it on the floating window
To Reproduce
Steps to reproduce the behavior:
Have any open window that is managed by komorebi
Open a new floating window (in my case that it everything search)
Try to close the floating window using komorebic close
The window behind gets closed (the bug)
Expected behavior
Close the floating window instead of the one behind it.
Screenshots and Videos
Operating System
OS Name: Microsoft Windows 10 Home Single Language
OS Version: 10.0.19045 N/A Build 19045
komorebic check Output
Additional context
I'm also unable to close the floating window even though that is the only open window that is focused in that workspace.
NOTE: I have not applied any window or workspace rules to everything search (the floating window).
Originally created by @Keshav13142 on GitHub (Aug 1, 2023).
**Describe the bug**
If I try to close a floating window using the wkhd shortcut I assigned to `komorebic close`, the window behind it gets closed even though the focus it on the floating window
**To Reproduce**
Steps to reproduce the behavior:
1. Have any open window that is managed by komorebi
2. Open a new floating window (in my case that it everything search)
3. Try to close the floating window using `komorebic close`
4. The window behind gets closed (the bug)
**Expected behavior**
Close the floating window instead of the one behind it.
**Screenshots and Videos**

**Operating System**
OS Name: Microsoft Windows 10 Home Single Language
OS Version: 10.0.19045 N/A Build 19045
**`komorebic check` Output**

**Additional context**
I'm also unable to close the floating window even though that is the only open window that is focused in that workspace.
> NOTE: I have not applied any window or workspace rules to `everything search` (the floating window).
The following are my configs
- [komorebi ](https://github.com/Keshav13142/.dotfiles-windows/blob/main/komorebi/.config/komorebi/komorebi.json)
- [wkhd ](https://github.com/Keshav13142/.dotfiles-windows/blob/main/whkd/.config/whkdrc)
adam
added the bug label 2026-01-05 14:49:10 +01:00
komorebic commands generally only operate on applications managed by the window manager, and Everything fails the window management validity test (since it's not a windowed application) meaning it gets ignored, therefore this is not a bug but the intended behaviour, because komorebi should only be able to operate on windows it manages.
I'd be open to a accepting PR if somebody felt strongly enough about this to add an additional command like close-any-window which explicitly documents that the command can operate on windows not managed by komorebi.
@LGUG2Z commented on GitHub (Aug 1, 2023):
`komorebic` commands generally only operate on applications managed by the window manager, and `Everything` fails the window management validity test (since it's not a windowed application) meaning it gets ignored, therefore this is not a bug but the intended behaviour, because `komorebi` should only be able to operate on windows it manages.
I'd be open to a accepting PR if somebody felt strongly enough about this to add an additional command like `close-any-window` which explicitly documents that the command can operate on windows not managed by `komorebi`.
komorebic commands generally only operate on applications managed by the window manager, and Everything fails the window management validity test (since it's not a windowed application) meaning it gets ignored, therefore this is not a bug but the intended behaviour, because komorebi should only be able to operate on windows it manages.
I'd be open to a accepting PR if somebody felt strongly enough about this to add an additional command like close-any-window which explicitly documents that the command can operate on windows not managed by komorebi.
Oh okay, makes sense!. I misunderstood that Everything was a floating window managed by Komorebi. I didn't know that it failed the validity test.
And yes, close-any-window sounds like a good feature, however I'm also not sure how many people have encountered this problem.
Thanks for the response.
@Keshav13142 commented on GitHub (Aug 7, 2023):
> `komorebic` commands generally only operate on applications managed by the window manager, and `Everything` fails the window management validity test (since it's not a windowed application) meaning it gets ignored, therefore this is not a bug but the intended behaviour, because `komorebi` should only be able to operate on windows it manages.
>
> I'd be open to a accepting PR if somebody felt strongly enough about this to add an additional command like `close-any-window` which explicitly documents that the command can operate on windows not managed by `komorebi`.
Oh okay, makes sense!. I misunderstood that `Everything` was a floating window managed by `Komorebi`. I didn't know that it failed the validity test.
And yes, `close-any-window` sounds like a good feature, however I'm also not sure how many people have encountered this problem.
Thanks for the response.
For anyone looking for a workaround, it's pretty straightforward to set up hotkeys that work for all windows (tiled, floating, full screen, monocle, or unmanaged) using AHK:
!x::WinMinimize,A ; Alt + x minimizes the active window !q::WinClose,A ; Alt + q closes the active window
@urob commented on GitHub (Nov 30, 2023):
For anyone looking for a workaround, it's pretty straightforward to set up hotkeys that work for all windows (tiled, floating, full screen, monocle, or unmanaged) using AHK:
```autohotkey
!x:: WinMinimize, A ; Alt + x minimizes the active window
!q:: WinClose, A ; Alt + q closes the active window
```
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Keshav13142 on GitHub (Aug 1, 2023).
Describe the bug
If I try to close a floating window using the wkhd shortcut I assigned to
komorebic close, the window behind it gets closed even though the focus it on the floating windowTo Reproduce
Steps to reproduce the behavior:
komorebic closeExpected behavior
Close the floating window instead of the one behind it.
Screenshots and Videos

Operating System
OS Name: Microsoft Windows 10 Home Single Language
OS Version: 10.0.19045 N/A Build 19045
komorebic checkOutputAdditional context
I'm also unable to close the floating window even though that is the only open window that is focused in that workspace.
The following are my configs
@LGUG2Z commented on GitHub (Aug 1, 2023):
komorebiccommands generally only operate on applications managed by the window manager, andEverythingfails the window management validity test (since it's not a windowed application) meaning it gets ignored, therefore this is not a bug but the intended behaviour, becausekomorebishould only be able to operate on windows it manages.I'd be open to a accepting PR if somebody felt strongly enough about this to add an additional command like
close-any-windowwhich explicitly documents that the command can operate on windows not managed bykomorebi.@Keshav13142 commented on GitHub (Aug 7, 2023):
Oh okay, makes sense!. I misunderstood that
Everythingwas a floating window managed byKomorebi. I didn't know that it failed the validity test.And yes,
close-any-windowsounds like a good feature, however I'm also not sure how many people have encountered this problem.Thanks for the response.
@urob commented on GitHub (Nov 30, 2023):
For anyone looking for a workaround, it's pretty straightforward to set up hotkeys that work for all windows (tiled, floating, full screen, monocle, or unmanaged) using AHK: