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
- Exit monocle mode (komorebic monocle-mode toggle) or unmaximize before moving
- Configure hotkeys to check state first and skip the move when monocle/maximized
- Treat the error as an expected no-op in hotkey handlers and swallow it
- 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
- Exit monocle/maximize before rearranging containers
- Route directional-move hotkeys through a state-aware dispatcher
- Treat this message as an expected no-op
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
- cannot move native maximized window to another monitor or wo
- 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/547ba3f39c2bc491.
Report an issue: GitHub.