wezterm/wezterm · error

to resolve my own window_id

Error message

to resolve my own window_id

What it means

wezterm panics with this message when the mux cannot find a window for the window_id that the launcher overlay was created with. In `LauncherOverlay::new` the overlay thread captures the tab list up front by calling `mux.get_window(mux_window_id)`, which returns an Option; the code asserts it must succeed because the id was just obtained from the mux itself. The expect() firing means the mux window registry no longer contains that id (e.g. the window was closed/removed from the mux between obtaining the id and building the overlay) or the id was somehow wrong/foreign.

Source

Thrown at wezterm-gui/src/overlay/launcher.rs:95

    ) -> Self {
        let mux = Mux::get();

        let active_workspace = mux.active_workspace();

        let workspaces = if flags.contains(LauncherFlags::WORKSPACES) {
            mux.iter_workspaces()
        } else {
            vec![]
        };

        let tabs = if flags.contains(LauncherFlags::TABS) {
            // Ideally we'd resolve the tabs on the fly once we've started the
            // overlay, but since the overlay runs in a different thread, accessing
            // the mux list is a bit awkward.  To get the ball rolling we capture
            // the list of tabs up front and live with a static list.
            let window = mux
                .get_window(mux_window_id)
                .expect("to resolve my own window_id");
            window
                .iter_tabs()
                .enumerate()
                .map(|(tab_idx, tab)| {
                    let tab_title = tab.get_title();
                    let title = if tab_title.is_empty() {
                        tab.get_active_pane()
                            .expect("tab to have a pane")
                            .get_title()
                    } else {
                        tab_title
                    };
                    LauncherTabEntry {
                        title,
                        tab_idx,
                        pane_count: tab.count_panes(),
                    }
                })

View on GitHub (pinned to 08e5e0afc6)

Solutions

  1. Update wezterm to the latest version; races between window close and launcher open have been fixed over time.
  2. Reproduce deterministically? File a bug with the wezterm GUI logs (WEZTERM_LOG=debug) including the steps that closed the window before opening the launcher.
  3. Avoid reusing cached window ids across mux reconnects: always re-resolve the current window id from the active pane before opening the launcher.
  4. If it occurs during development/embedding, verify the mux_window_id passed to LauncherOverlay::new came from the same live mux instance.
  5. As a stopgap, restart the GUI window/process; the panic is non-recoverable for that overlay thread.

Example fix

// before
let window = mux
    .get_window(mux_window_id)
    .expect("to resolve my own window_id");
// after (defensive, mirrors the library's own fix style)
let window = mux.get_window(mux_window_id)
    .with_context(|| format!("window {mux_window_id:?} missing from mux when opening launcher"))?;
Defensive patterns

Strategy: try-catch

Validate before calling

// Before opening the launcher programmatically, verify the window still exists:
let window_exists = mux.get_window(mux_window_id).is_some();
if !window_exists { /* re-resolve window id or abort */ }

Type guard

fn window_is_live(mux: &Mux, window_id: MuxWindowId) -> bool {
    mux.get_window(window_id).is_some()
}

Try / catch

// This is a panic (expect), not a Result; as an embedder, catch_unwind around overlay creation:
let result = std::panic::catch_unwind(|| open_launcher_overlay(mux_window_id));
match result {
    Ok(overlay) => overlay,
    Err(_) => { /* log and re-resolve the window id, then retry */ }
}

Prevention

When it happens

Trigger: Calling `mux.get_window(mux_window_id)` inside `LauncherOverlay::new` when the mux_window_id does not exist in the mux: the window was closed concurrently, the id belongs to a different mux instance/domain (e.g. after detaching/re-attaching or across a mux server restart), or a stale id was passed in from another thread.

Common situations: Opening the launcher (Ctrl-Shift-L / spawn_command) in a race with window close or mux server shutdown; connecting to a mux domain whose server restarted so window ids were regenerated; programmatic API/script use that caches a window_id and reuses it later after the window is gone.

Related errors

AI-assisted analysis of wezterm/wezterm@08e5e0afc6 (2026-08-30). Data as JSON: /api/errors/21b355f8c5dee4ac. Report an issue: GitHub.