LGUG2Z/komorebi · info

ignoring command while active window is in monocle mode or m

Error message

ignoring command while active window is in monocle mode or maximized

What it means

move_container_in_direction early-returns an error when the focused window is in monocle mode or is (native) maximized. Rearranging containers in a direction is meaningless/unsafe for a window occupying the whole workspace, so komorebi bails before computing origin/target indices.

Source

Thrown at komorebi/src/window_manager.rs:2392

        }

        Ok(())
    }

    #[tracing::instrument(skip(self))]
    pub fn move_container_in_direction(
        &mut self,
        direction: OperationDirection,
    ) -> eyre::Result<()> {
        self.handle_unmanaged_window_behaviour()?;

        let workspace = self.focused_workspace()?;
        let workspace_idx = self.focused_workspace_idx()?;

        // removing this messes up the monitor / container / window index somewhere
        // and results in the wrong window getting moved across the monitor boundary
        if workspace.is_focused_window_monocle_or_maximized()? {
            bail!("ignoring command while active window is in monocle mode or maximized");
        }

        tracing::info!("moving container");

        let origin_container_idx = workspace.focused_container_idx();
        let origin_monitor_idx = self.focused_monitor_idx();
        let target_container_idx = workspace.new_idx_for_direction(direction);

        // this is for when we are scrolling across workspaces like PaperWM
        if target_container_idx.is_none()
            && matches!(
                self.cross_boundary_behaviour,
                CrossBoundaryBehaviour::Workspace
            )
            && matches!(
                direction,
                OperationDirection::Left | OperationDirection::Right
            )

View on GitHub (pinned to e0709f02bf)

Solutions

  1. Exit monocle mode (komorebic monocle-mode toggle) or unmaximize before moving
  2. Configure hotkeys to check state first and skip the move when monocle/maximized
  3. Treat the error as an expected no-op in hotkey handlers and swallow it
  4. Verify the focused window is actually tiled if the error seems spurious

Example fix

// before
komorebic move left // fails in monocle mode
// after
komorebic monocle-mode toggle 2>/dev/null; komorebic move left
Defensive patterns

Strategy: try-catch

Validate before calling

// only issue directional moves when not in monocle/maximized state
// (komorebi config can use "until" conditions for such commands)

Try / catch

match komorebic move left {
    Err(e) if e.contains("monocle mode or maximized") => Ok(()), // expected no-op
    other => other,
}

Prevention

When it happens

Trigger: Calling move_container_in_direction (move-left/right/up/down keybinds, komorebic move) while is_focused_window_monocle_or_maximized() returns true — window is in monocle layout or maximized state.

Common situations: User toggles monocle (komorebic monocle-mode) or maximizes a window, then presses directional move hotkeys; hotkey daemons send the command unconditionally.

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


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