LGUG2Z/komorebi · warning

ignoring commands while active window is not managed by komo

Error message

ignoring commands while active window is not managed by komorebi

What it means

handle_unmanaged_window_behaviour checks, when the unmanaged window operation behaviour is not NoOp, that the currently focused (foreground) window is actually managed by komorebi before executing directional/cycle focus and move commands. If the foreground window is unmanaged (e.g. a floating-over app or a non-managed popup), it bails to prevent commands targeting a window komorebi does not control.

Source

Thrown at komorebi/src/window_manager.rs:1478

                        window.remove_accent()?;
                    }
                }
            }
        }

        Ok(())
    }

    #[tracing::instrument(skip(self))]
    fn handle_unmanaged_window_behaviour(&self) -> eyre::Result<()> {
        if matches!(
            self.unmanaged_window_operation_behaviour,
            OperationBehaviour::NoOp
        ) {
            let workspace = self.focused_workspace()?;
            let focused_hwnd = WindowsApi::foreground_window()?;
            if !workspace.contains_managed_window(focused_hwnd) {
                bail!("ignoring commands while active window is not managed by komorebi");
            }
        }

        Ok(())
    }

    /// Check for an existing wallpaper definition on the workspace/monitor index pair and apply it
    /// if it exists
    #[tracing::instrument(skip(self))]
    pub fn apply_wallpaper_for_monitor_workspace(
        &mut self,
        monitor_idx: usize,
        workspace_idx: usize,
    ) -> eyre::Result<()> {
        let monitor = self
            .monitors_mut()
            .get_mut(monitor_idx)
            .ok_or_eyre("there is no monitor")?;

View on GitHub (pinned to e0709f02bf)

Solutions

1. Click into a managed window (or use alt-tab to one) before issuing focus/move keybinds.
2. Check unmanaged_window_operation_behaviour config — adjust it if you want commands to operate anyway.
3. Identify the unmanaged window with komorebic query / wininfo and add/manage it appropriately (manage command or rules) if it should be managed.
4. Close or dismiss overlay windows stealing foreground focus.

Example fix

// before
# keybind fired while an unmanaged overlay had focus -> error
// after
"unmanaged_window_operation_behaviour": "Op"  // in komorebi.json, to allow operating anyway

// Check the foreground window is managed before issuing commands
komorebic focused-window   # errors/empty if the focused window is unmanaged

fn command_targets_managed_window(ws: &Workspace, hwnd: isize) -> bool {
    ws.contains_managed_window(hwnd)
}

if let Err(e) = wm.handle_unmanaged_window_behaviour() {
    tracing::debug!("command ignored: {e}"); // focus is on an unmanaged window; skip instead of failing
}

When it happens

Trigger: Invoking move_container_to_monitor, move_container_to_workspace, focus_container_in_direction/cycle_direction, or move_container_in_direction/cycle_direction (via keybinds) while the foreground window is not in the focused workspace's managed set — e.g. focus is on a topmost/unmanaged app, a UWP flyout, or the desktop.

Common situations: Pressing focus/move keybinds while an always-on-top tool, screenshot overlay, or taskbar has focus; focus left on a floating window excluded from management; clicking the desktop then using keybinds.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

• cannot move native maximized window to another monitor or wo
• could not close window

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