Originally created by @josswright on GitHub (Oct 25, 2025).
Summary
(This isn't a duplicate of https://github.com/LGUG2Z/komorebi/issues/1464, as far as I'm aware. That seems to refer to WezTerm installed via WSL and running via WSLg. This is for the Windows build of WezTerm running natively.)
I've been using the Windows build of WezTerm on my Windows desktop machine, and just installed it on my laptop. I tend to run WezTerm with the window_decorations = "RESIZE" so that there's no title bar.
On my desktop, I often notice that WezTerm doesn't honour my masir focus-follows-mouse setup, but that I can switch focus to it manually with komorebi hotkeys or an explicit mouse click. Despite this, it is tiled as for other windows, and can be moved, moved to another monitor, moved to another workspace as usual.
However, having just installed it on my laptop and copied over my configurations for komorebi, whkd, masir, and WezTerm, WezTerm is completely unmanaged by komorebi when it opens. If I change my config to window_decorations = "TITLE | RESIZE" (the default, with titlebar) then komorebi does tile and manage it, but focus following mouse is still not working.
I went to look at forcing komorebi to manage WezTerm, in case it was in the ignore list, but komorebic visible-windows doesn't list the WezTerm window, even when the titlebar is enabled and komorebi tiles it properly.
I've tried with the latest release version of WezTerm, and the nightly build.
Version Information
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.26100 N/A Build 26100
### Hotkey Configuration
.shell powershell
# Reload whkd configuration
win + shift + r : komorebic reload-configuration ; taskkill /f /im whkd.exe; Start-Process whkd -WindowStyle hidden
# App shortcuts - these require shell to be pwsh / powershell
# The apps will be focused if open, or launched if not open
win + ctrl + e : if ($wshell.AppActivate('wt') -eq $False) { start wt }
# win + f : if ($wshell.AppActivate('Firefox') -eq $False) { start firefox }
win + space : komorebic close
# Focus windows
win + h : komorebic focus left
win + j : komorebic focus down
win + k : komorebic focus up
win + l : komorebic focus right
# Move windows
win + control + h : komorebic move left
win + control + j : komorebic move down
win + control + k : komorebic move up
win + control + l : komorebic move right
win + control + return : komorebic promote
# Stack windows
win + left : komorebic stack left
win + down : komorebic stack down
win + up : komorebic stack up
win + right : komorebic stack right
# Manipulate windows
control + win + space : komorebic toggle-float
win + m : komorebic toggle-maximize
# Workspaces
win + oem_4 : komorebic focus-workspace 0
win + oem_6 : komorebic focus-workspace 1
win + oem_1 : komorebic focus-workspace 2
win + oem_7 : komorebic focus-workspace 3
win + oem_3 : komorebic focus-workspace 3
win + oem_comma : komorebic focus-workspace 5
win + oem_period : komorebic focus-workspace 6
win + oem_2 : komorebic focus-workspace 7
# Move windows across workspaces
win + shift + oem_4 : komorebic send-to-workspace 0
win + shift + oem_6 : komorebic send-to-workspace 1
win + shift + oem_1 : komorebic send-to-workspace 2
win + shift + oem_7 : komorebic send-to-workspace 3
win + shift + oem_3 : komorebic send-to-workspace 3
win + shift + oem_comma : komorebic send-to-workspace 5
win + shift + oem_period : komorebic send-to-workspace 6
win + shift + oem_2 : komorebic send-to-workspace 7
win + shift + oem_4 : komorebic send-to-workspace 0
# Move between workspaces
win + shift + l : komorebic cycle-workspace next
win + shift + h : komorebic cycle-workspace previous
# Move between monitors
win + o : komorebic cycle-move-to-monitor next
Output of komorebic check
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\<username>
Looking for configuration files in C:\Users\<username>
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\<username>\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag
Originally created by @josswright on GitHub (Oct 25, 2025).
### Summary
(This isn't a duplicate of https://github.com/LGUG2Z/komorebi/issues/1464, as far as I'm aware. That seems to refer to WezTerm installed via WSL and running via WSLg. This is for the Windows build of WezTerm running natively.)
I've been using the Windows build of WezTerm on my Windows desktop machine, and just installed it on my laptop. I tend to run WezTerm with the `window_decorations = "RESIZE"` so that there's no title bar.
On my desktop, I often notice that WezTerm doesn't honour my masir focus-follows-mouse setup, but that I can switch focus to it manually with komorebi hotkeys or an explicit mouse click. Despite this, it is tiled as for other windows, and can be moved, moved to another monitor, moved to another workspace as usual.
However, having just installed it on my laptop and copied over my configurations for komorebi, whkd, masir, and WezTerm, WezTerm is completely unmanaged by komorebi when it opens. If I change my config to `window_decorations = "TITLE | RESIZE"` (the default, with titlebar) then komorebi does tile and manage it, but focus following mouse is still not working.
I went to look at forcing komorebi to manage WezTerm, in case it was in the ignore list, but `komorebic visible-windows` doesn't list the WezTerm window, even when the titlebar is enabled and komorebi tiles it properly.
I've tried with the latest release version of WezTerm, and the nightly build.
### Version Information
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.26100 N/A Build 26100
komorebic 0.1.38
tag:v0.1.38
commit_hash:ffa76ea2
build_time:2025-09-13 18:40:25 +00:00
build_env:rustc 1.89.0 (29483883e 2025-08-04),stable-x86_64-pc-windows-msvc
### Komorebi Configuration
```json
{
"schema": "https://raw.githubusercontent.com/LGUG2Z/komorebi/v0.1.34/schema.json",
"app_specific_configuration_path": "$Env:USERPROFILE/applications.json",
"window_hiding_behaviour": "Cloak",
"cross_monitor_move_behaviour": "Insert",
"mouse_follows_focus": true,
"default_workspace_padding": 4,
"default_container_padding": 4,
"border": true,
"border_width": 2,
"border_offset": 0,
"theme": {
"palette": "Base16",
"name": "Pop",
"unfocused_border": "Base03",
"bar_accent": "Base0D"
},
"animation": {
"enabled": false,
"duration": 200
},
"bar_configurations": [
"$Env:USERPROFILE/komorebi.bar-primary.json",
"$Env:USERPROFILE/komorebi.bar-secondary.json"
],
"stackbar": {
"height": 32,
"mode": "OnStack",
"tabs": {
"width": 300
}
},
"monitors": [
{
"workspaces": [
{
"name": "金",
"layout": "VerticalStack"
},
{
"name": "水",
"layout": "VerticalStack"
},
{
"name": "土",
"layout": "VerticalStack"
},
{
"name": "木",
"layout": "VerticalStack"
},
{
"name": "木",
"layout": "VerticalStack"
},
{
"name": "阴",
"layout": "VerticalStack"
},
{
"name": "阳",
"layout": "VerticalStack"
},
{
"name": "正",
"layout": "VerticalStack"
}
]
},
{
"workspaces": [
{
"name": "金",
"layout": "VerticalStack"
},
{
"name": "水",
"layout": "VerticalStack"
},
{
"name": "土",
"layout": "VerticalStack"
},
{
"name": "木",
"layout": "VerticalStack"
},
{
"name": "火",
"layout": "VerticalStack"
},
{
"name": "阴",
"layout": "VerticalStack"
},
{
"name": "阳",
"layout": "VerticalStack"
},
{
"name": "正",
"layout": "VerticalStack"
}
]
}
]
}
```
```
### Hotkey Configuration
.shell powershell
# Reload whkd configuration
win + shift + r : komorebic reload-configuration ; taskkill /f /im whkd.exe; Start-Process whkd -WindowStyle hidden
# App shortcuts - these require shell to be pwsh / powershell
# The apps will be focused if open, or launched if not open
win + ctrl + e : if ($wshell.AppActivate('wt') -eq $False) { start wt }
# win + f : if ($wshell.AppActivate('Firefox') -eq $False) { start firefox }
win + space : komorebic close
# Focus windows
win + h : komorebic focus left
win + j : komorebic focus down
win + k : komorebic focus up
win + l : komorebic focus right
# Move windows
win + control + h : komorebic move left
win + control + j : komorebic move down
win + control + k : komorebic move up
win + control + l : komorebic move right
win + control + return : komorebic promote
# Stack windows
win + left : komorebic stack left
win + down : komorebic stack down
win + up : komorebic stack up
win + right : komorebic stack right
# Manipulate windows
control + win + space : komorebic toggle-float
win + m : komorebic toggle-maximize
# Workspaces
win + oem_4 : komorebic focus-workspace 0
win + oem_6 : komorebic focus-workspace 1
win + oem_1 : komorebic focus-workspace 2
win + oem_7 : komorebic focus-workspace 3
win + oem_3 : komorebic focus-workspace 3
win + oem_comma : komorebic focus-workspace 5
win + oem_period : komorebic focus-workspace 6
win + oem_2 : komorebic focus-workspace 7
# Move windows across workspaces
win + shift + oem_4 : komorebic send-to-workspace 0
win + shift + oem_6 : komorebic send-to-workspace 1
win + shift + oem_1 : komorebic send-to-workspace 2
win + shift + oem_7 : komorebic send-to-workspace 3
win + shift + oem_3 : komorebic send-to-workspace 3
win + shift + oem_comma : komorebic send-to-workspace 5
win + shift + oem_period : komorebic send-to-workspace 6
win + shift + oem_2 : komorebic send-to-workspace 7
win + shift + oem_4 : komorebic send-to-workspace 0
# Move between workspaces
win + shift + l : komorebic cycle-workspace next
win + shift + h : komorebic cycle-workspace previous
# Move between monitors
win + o : komorebic cycle-move-to-monitor next
```
### Output of komorebic check
```
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\<username>
Looking for configuration files in C:\Users\<username>
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\<username>\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag
```
As an update: I just discovered an issue for yabai which seems to be describing similar behaviour.
It seems that if I run Wezterm before komorebi starts, this behaviour of WezTerm being unmanaged happens and persists even if I then close WezTerm; it looks like because WezTerm leaves a process open even after closing all windows then the unmanaged state is preserved.
If I manually kill the WezTerm process in Task Manager and then restart, then komorebi does then start to tile the window correctly. (Alternatively, if I make sure that I wait until komorebi is loaded before first starting WezTerm then the problem never turns up.)
This still leaves the problem of WezTerm somehow not being considered a window by masir for the purposes of focus following mouse, so there is still something odd going on. At least there's a workaround for the tiling itself, though.
@josswright commented on GitHub (Nov 4, 2025):
As an update: I just discovered an [issue](https://github.com/koekeishiya/yabai/issues/2190) for `yabai` which seems to be describing similar behaviour.
It seems that if I run Wezterm before komorebi starts, this behaviour of WezTerm being unmanaged happens and persists even if I then close WezTerm; it looks like because WezTerm leaves a process open even after closing all windows then the unmanaged state is preserved.
If I manually kill the WezTerm process in Task Manager and then restart, then komorebi does then start to tile the window correctly. (Alternatively, if I make sure that I wait until komorebi is loaded before first starting WezTerm then the problem never turns up.)
This still leaves the problem of WezTerm somehow not being considered a window by `masir` for the purposes of focus following mouse, so there is still something odd going on. At least there's a workaround for the tiling itself, though.
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 @josswright on GitHub (Oct 25, 2025).
Summary
(This isn't a duplicate of https://github.com/LGUG2Z/komorebi/issues/1464, as far as I'm aware. That seems to refer to WezTerm installed via WSL and running via WSLg. This is for the Windows build of WezTerm running natively.)
I've been using the Windows build of WezTerm on my Windows desktop machine, and just installed it on my laptop. I tend to run WezTerm with the
window_decorations = "RESIZE"so that there's no title bar.On my desktop, I often notice that WezTerm doesn't honour my masir focus-follows-mouse setup, but that I can switch focus to it manually with komorebi hotkeys or an explicit mouse click. Despite this, it is tiled as for other windows, and can be moved, moved to another monitor, moved to another workspace as usual.
However, having just installed it on my laptop and copied over my configurations for komorebi, whkd, masir, and WezTerm, WezTerm is completely unmanaged by komorebi when it opens. If I change my config to
window_decorations = "TITLE | RESIZE"(the default, with titlebar) then komorebi does tile and manage it, but focus following mouse is still not working.I went to look at forcing komorebi to manage WezTerm, in case it was in the ignore list, but
komorebic visible-windowsdoesn't list the WezTerm window, even when the titlebar is enabled and komorebi tiles it properly.I've tried with the latest release version of WezTerm, and the nightly build.
Version Information
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.26100 N/A Build 26100
komorebic 0.1.38
tag:v0.1.38
commit_hash:ffa76ea2
build_time:2025-09-13 18:40:25 +00:00
build_env:rustc 1.89.0 (29483883e 2025-08-04),stable-x86_64-pc-windows-msvc
Komorebi Configuration
Output of komorebic check
@josswright commented on GitHub (Nov 4, 2025):
As an update: I just discovered an issue for
yabaiwhich seems to be describing similar behaviour.It seems that if I run Wezterm before komorebi starts, this behaviour of WezTerm being unmanaged happens and persists even if I then close WezTerm; it looks like because WezTerm leaves a process open even after closing all windows then the unmanaged state is preserved.
If I manually kill the WezTerm process in Task Manager and then restart, then komorebi does then start to tile the window correctly. (Alternatively, if I make sure that I wait until komorebi is loaded before first starting WezTerm then the problem never turns up.)
This still leaves the problem of WezTerm somehow not being considered a window by
masirfor the purposes of focus following mouse, so there is still something odd going on. At least there's a workaround for the tiling itself, though.