komorebi doesn't use config komorebi.ahk file #88

New Issue

2026-01-05T14:48:13+01:00

adam commented

2026-01-05 14:48:13 +01:00

Originally created by @labuut on GitHub (May 26, 2022).

Hello. Please, help me to understand how i can make komorebi to use config komorebi.ahk.

Details:

OS: Windows 10, komorebi's release: komorebi-0.1.9-x86_64-pc-windows-msvc
komorebi's files (komorebic.exe and komorebi.exe) were moved to ...\Program Files\komorebi (added to Path):
```
    $Env:Path.split(";")
    ...
    C:\Program Files\komorebi
```
I've made the directory for komorebi's config (C:\Users\userName\.komorebi) and create env var for it:
```
    $Env:KOMOREBI_CONFIG_HOME
    C:\Users\userName\.komorebi
```
komorebi.sample.ahk was renamed to komorebi.ahk and moved to KOMOREBI_CONFIG_HOME. I've done some changes in this file (reassign some keys, update some offsets, add a few new hotkeys) as well.
Then I started komorebi by powerShell command komorebi start. It starts working.
But I can't cee my updated offsets (invisible-borders or work-area-offset), I can't use reassigned keys and new hotkeys. Only built-in hotkeys (predefined in komorebi.sample.ahk) work. If I run komorebi.ahk with autoHotkey my new and reassigned hotkeys start working. But offsets don't update as well.

So, my questions:

How can I understand, that komorebi use config komorebi.ahk from KOMOREBI_CONFIG_HOME?
How can I make komorebi use config komorebi.ahk from KOMOREBI_CONFIG_HOME? I've used params reload-configuration watch-configuration in powerShell but I can't see any changes.
Should I every time run komorebi only using by powerShell command komorebi start? Or I can use komorebi(c).exe file?

Originally created by @labuut on GitHub (May 26, 2022). Hello. Please, help me to understand how i can make komorebi to use config komorebi.ahk. Details: 1. OS: Windows 10, komorebi's release: `komorebi-0.1.9-x86_64-pc-windows-msvc` 2. komorebi's files (`komorebic.exe` and `komorebi.exe`) were moved to `...\Program Files\komorebi` (added to `Path`): ``` $Env:Path.split(";") ... C:\Program Files\komorebi ``` 3. I've made the directory for komorebi's config (`C:\Users\userName\.komorebi`) and create env var for it: ``` $Env:KOMOREBI_CONFIG_HOME C:\Users\userName\.komorebi ``` 4. `komorebi.sample.ahk` was renamed to `komorebi.ahk` and moved to `KOMOREBI_CONFIG_HOME`. I've done some changes in this file (reassign some keys, update some offsets, add a few new hotkeys) as well. 5. Then I started komorebi by powerShell command `komorebi start`. It starts working. But I can't cee my updated offsets (invisible-borders or work-area-offset), I can't use reassigned keys and new hotkeys. Only built-in hotkeys (predefined in `komorebi.sample.ahk`) work. If I run `komorebi.ahk` with autoHotkey my new and reassigned hotkeys start working. But offsets don't update as well. So, my questions: 1. How can I understand, that komorebi use config `komorebi.ahk` from `KOMOREBI_CONFIG_HOME`? 2. How can I make komorebi use config `komorebi.ahk` from `KOMOREBI_CONFIG_HOME`? I've used params `reload-configuration` `watch-configuration` in powerShell but I can't see any changes. 4. Should I every time run komorebi only using by powerShell command `komorebi start`? Or I can use `komorebi(c).exe` file?

adam closed this issue

2026-01-05 14:48:13 +01:00

adam commented

2026-01-05 14:48:14 +01:00

@jmml97 commented on GitHub (May 26, 2022):

I'm having this problem too. komorebi is not reading the $Env:UserProfile\komorebi.ahk file. There's no message on the log that could help.

@jmml97 commented on GitHub (May 26, 2022): I'm having this problem too. `komorebi` is not reading the `$Env:UserProfile\komorebi.ahk` file. There's no message on the log that could help.

adam commented

2026-01-05 14:48:14 +01:00

@LGUG2Z commented on GitHub (May 26, 2022):

When the configuration is available to be loaded, you should get a line like this come through in the logs during the startup phase:

1:12:58.327088Z  INFO komorebi: loading configuration file: C:\Users\LGUG2Z\.config\komorebi\komorebi.ahk

The configuration loader (and reloader) essentially depends on two checks. The first is to determine the version of AHK based on looking for a specific executable name in your PATH, and then based on the version that is present, loading either komorebi.ahk or komorebi.ahk2.

I'm assuming that you're using the AHK v1 format since you're modifying the sample, so make sure you have autohotkey.exe in your PATH.

The other thing to check is the versions of PowerShell that you are using. If you're on Windows 10, you probably have both PowerShell 5, 6 and 7 installed. Unfortunately, the profile configuration files for these two versions are held in different locations:

~/Documents/WindowsPowerShell/Microsoft.PowerShell_profile.ps1 - V5, V6
~/Documents/PowerShell/Microsoft.PowerShell_profile.ps1 - V7

If you use multiple versions of PowerShell concurrently, make sure you have set $Env:KOMOREBI_CONFIG_HOME in all the relevant profile files.

Finally, you should always start komorebi by running komorebic start from PowerShell, and from the version of PowerShell that will load your custom $Env:KOMOREBI_CONFIG_HOME variable from the correct profile file.

tl;dr This is most likely either a PowerShell environment configuration issue, or a case of the expected AHK executable not being found.

@LGUG2Z commented on GitHub (May 26, 2022): When the configuration is available to be loaded, you should get a line like this come through in the logs during the startup phase: ``` 1:12:58.327088Z INFO komorebi: loading configuration file: C:\Users\LGUG2Z\.config\komorebi\komorebi.ahk ``` The configuration loader (and reloader) essentially depends on [two checks](https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/main.rs#L190). The first is to determine the version of AHK based on looking for a specific executable name in your `PATH`, and then based on the version that is present, loading either `komorebi.ahk` or `komorebi.ahk2`. I'm assuming that you're using the AHK v1 format since you're modifying the sample, so make sure you have `autohotkey.exe` in your `PATH`. The other thing to check is the versions of PowerShell that you are using. If you're on Windows 10, you probably have both PowerShell 5, 6 and 7 installed. Unfortunately, the profile configuration files for these two versions are held in different locations: `~/Documents/WindowsPowerShell/Microsoft.PowerShell_profile.ps1` - V5, V6 `~/Documents/PowerShell/Microsoft.PowerShell_profile.ps1` - V7 If you use multiple versions of PowerShell concurrently, make sure you have set `$Env:KOMOREBI_CONFIG_HOME` in all the relevant profile files. Finally, you should always start `komorebi` by running `komorebic start` from PowerShell, and from the version of PowerShell that will load your custom `$Env:KOMOREBI_CONFIG_HOME` variable from the correct profile file. tl;dr This is most likely either a PowerShell environment configuration issue, or a case of the expected AHK executable not being found.

adam commented

2026-01-05 14:48:14 +01:00

@tgharib commented on GitHub (May 28, 2022):

Adding C:\Program Files\AutoHotkey to my system-level PATH and restarting my PC fixed this issue for me.

@tgharib commented on GitHub (May 28, 2022): Adding `C:\Program Files\AutoHotkey` to my system-level `PATH` and restarting my PC fixed this issue for me.

adam commented

2026-01-05 14:48:14 +01:00

@jmml97 commented on GitHub (May 28, 2022):

Indeed, adding C:\Program Files\AutoHotkey to the system-level PATH seems to fix this issue.

@jmml97 commented on GitHub (May 28, 2022): Indeed, adding `C:\Program Files\AutoHotkey` to the system-level `PATH` seems to fix this issue.

adam commented

2026-01-05 14:48:15 +01:00

@labuut commented on GitHub (May 28, 2022):

LGUG2Z Thank you for such a verbose answer. As reported above the problem was that autohotkey's folder wasn't in PATH. Adding it to the system-level PATH fixed this issue.
komorebi is a great app, thank you for it.

@labuut commented on GitHub (May 28, 2022): [LGUG2Z](https://github.com/LGUG2Z) Thank you for such a verbose answer. As reported above the problem was that autohotkey's folder wasn't in PATH. Adding it to the system-level PATH fixed this issue. komorebi is a great app, thank you for it.

adam commented

2026-01-05 14:48:15 +01:00

@calendulish commented on GitHub (Jun 13, 2022):

It still a issue, because I follow the tutorial on readme and can't make it works because readme mention AutoHotKey64.exe file and not mention AutoHotKey.exe. I just make it working after read this issue. I'm using the portable version of AutoHotKey and the executable name that I have originally on the zip are AutoHotkeyU64.exe and using it or rename it to AutoHotKey64.exe don't work (it's already on path). I think the readme must be clarified or loader modified to support these names as well

@calendulish commented on GitHub (Jun 13, 2022): It still a issue, because I follow the tutorial on readme and can't make it works because readme mention AutoHotKey64.exe file and not mention AutoHotKey.exe. I just make it working after read this issue. I'm using the portable version of AutoHotKey and the executable name that I have originally on the zip are AutoHotkeyU64.exe and using it or rename it to AutoHotKey64.exe don't work (it's already on path). I think the readme must be clarified or loader modified to support these names as well

adam commented

2026-01-05 14:48:15 +01:00

@LGUG2Z commented on GitHub (Jun 13, 2022):

It sounds like a good idea to specify that the preferred way to install AHK is with scoop. I think that besides this, we can add environment variables to specify a custom executable name for the AHK binary to test for (for both v1 and v2) for people who don't want to use scoop. I've reopened this issue and will work on this a little later.

@LGUG2Z commented on GitHub (Jun 13, 2022): It sounds like a good idea to specify that the preferred way to install AHK is with `scoop`. I think that besides this, we can add environment variables to specify a custom executable name for the AHK binary to test for (for both v1 and v2) for people who don't want to use `scoop`. I've reopened this issue and will work on this a little later.

adam referenced this issue

2026-01-05 14:50:47 +01:00

[FEAT]: ability to swap focused WS on one monitor with visible WS on other monitor #445

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/komorebi#88