LGUG2Z/komorebi · warning

cannot move native maximized window to another monitor or wo

Error message

cannot move native maximized window to another monitor or workspace

What it means

komorebi refuses to move a container to another monitor or workspace when the workspace's focused/registered window is a native (Windows-managed) maximized window. Native maximization hands the window's geometry to the OS, so komorebi cannot safely re-target its area on a different monitor's work area. The check happens before any monitor-to-monitor transfer is attempted in move_container_to_monitor.

Source

Thrown at komorebi/src/window_manager.rs:1635

        {
            return self.move_container_to_workspace(workspace_idx, follow, None);
        }

        let offset = self.work_area_offset;
        let mouse_follows_focus = self.mouse_follows_focus;

        let monitor = self
            .focused_monitor_mut()
            .ok_or_eyre("there is no monitor")?;

        let current_area = monitor.work_area_size;

        let workspace = monitor
            .focused_workspace_mut()
            .ok_or_eyre("there is no workspace")?;

        if workspace.maximized_window.is_some() {
            bail!("cannot move native maximized window to another monitor or workspace");
        }

        let foreground_hwnd = WindowsApi::foreground_window()?;
        let floating_window_index = workspace
            .floating_windows()
            .iter()
            .position(|w| w.hwnd == foreground_hwnd);

        let floating_window =
            floating_window_index.and_then(|idx| workspace.floating_windows_mut().remove(idx));
        let container = if floating_window_index.is_none() {
            Some(
                workspace
                    .remove_focused_container()
                    .ok_or_eyre("there is no container")?,
            )
        } else {
            None

View on GitHub (pinned to e0709f02bf)

Solutions

1. Restore the window from native maximization (unmaximize) before issuing the move command
2. Use komorebi's own maximize/monocle toggle instead of native OS maximization so windows stay in komorebi's layout model
3. Wrap the command in a pre-check or catch the error and no-op instead of surfacing it to the user
4. Update komorebi — newer versions handle maximized-window monitor moves more gracefully

Example fix

// before
komorebic focus-monitor 1 // fails if focused window is natively maximized
// after
komorebic toggle-maximize  // unmaximize first
komorebic focus-monitor 1

// komorebi.json (v0.1.26+) dynamic function guard:
{
  "type": "komorebic",
  "args": ["cycle-monitor"],
  "until": "handle-unmanaged-windows"
}
// or in a script: check the focused workspace's maximized_window before moving

When it happens

Trigger: Calling move_container_to_monitor (directly or via process_command for the cycle-monitor/monitor-swap keybinds) while the source workspace has workspace.maximized_window set to Some — i.e. the user native-maximized a window (komorebi native maximization mode) and then attempts a monitor/workspace move.

Common situations: Users with komorebi.bar or native maximize behaviour pressing monitor-cycle hotkeys (e.g. komorebic cycle-monitor or move-window-to-monitor) while a browser/IDE is maximized via the OS; configs using 'komorebic maximize' with native management enabled.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

• ignoring command while active window is in monocle mode or m
• failed to find a window to move
• there is only one window in this container
• there is no window in this container at index {idx}
• a container must have at least one window

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