LGUG2Z/komorebi · critical

failed call to AllowSetForegroundWindow after 5 retries

Error message

failed call to AllowSetForegroundWindow after 5 retries

What it means

During komorebi startup, after a window operation the main loop calls AllowSetForegroundWindow to let the foreground window be set; it retries up to 5 times on failure. If all retries fail, it bails with this error and komorebi exits.

Source

Thrown at komorebi/src/main.rs:219

    CUSTOM_FFM.store(opts.focus_follows_mouse, Ordering::SeqCst);

    let mut set_foreground_window_retries = 5;
    let mut set_foreground_window_succeeded = false;

    let process_id = WindowsApi::current_process_id();
    while set_foreground_window_retries > 0 && !set_foreground_window_succeeded {
        match WindowsApi::allow_set_foreground_window(process_id) {
            Ok(_) => {
                set_foreground_window_succeeded = true;
            }
            Err(error) => {
                tracing::error!("{error}");
                set_foreground_window_retries -= 1;
            }
        }

        if set_foreground_window_retries == 0 {
            bail!("failed call to AllowSetForegroundWindow after 5 retries");
        }
    }

    WindowsApi::set_process_dpi_awareness_context()?;

    let session_id = WindowsApi::process_id_to_session_id()?;
    SESSION_ID.store(session_id, Ordering::SeqCst);

    let mut system = sysinfo::System::new();
    system.refresh_processes(ProcessesToUpdate::All, true);

    let matched_procs: Vec<&Process> = system.processes_by_name("komorebi.exe".as_ref()).collect();

    if matched_procs.len() > 1 {
        let mut len = matched_procs.len();
        for proc in matched_procs {
            if let Some(executable_path) = proc.exe()
                && executable_path.to_string_lossy().contains("shims")

View on GitHub (pinned to e0709f02bf)

Solutions

1. Run komorebi inside a normal interactive desktop session, not as a service or scheduled task without a desktop.
2. Retry after confirming no other app holds foreground lock; restart the shell/explorer if stale.
3. Check group policy / security software restrictions on AllowSetForegroundWindow.
4. Update komorebi — later versions may have adjusted the foreground handoff logic.

Example fix

// before
# running komorebi via SSH session (no interactive desktop)
// after
# launch komorebi from a logged-in desktop session (e.g. komorebic start in a normal terminal)

// Before launching, confirm an interactive desktop session
if (!Environment.UserInteractive) throw new InvalidOperationException("komorebi requires an interactive desktop session");

match std::panic::catch_unwind(komorebi_main) {
    Err(_) => eprintln!("AllowSetForegroundWindow failed 5x — run inside an interactive session"),
    Ok(v) => v,
}

When it happens

Trigger: Five consecutive Win32 AllowSetForegroundWindow failures during main() startup — typically a failing HWND, another process holding foreground rights, or restricted window station/desktop access.

Common situations: Running komorebi in a non-interactive session (service/SSH), foreground lock imposed by Windows when another app holds foreground permission, antivirus/policy restrictions on window APIs.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• window handles for move operation don't match: {} != {}
• could not close window
• could not find next window
• could not determine current session id
• could not find device_id for hmonitor: {hmonitor}

AI-assisted analysis of LGUG2Z/komorebi@e0709f02bf (2026-09-06). Data as JSON: /api/errors/8816b872a6548aec. Report an issue: GitHub.