LGUG2Z/komorebi · critical

unable to get exec path

Error message

unable to get exec path

What it means

komorebic-no-console is a thin wrapper binary that shells out to komorebic.exe located next to itself, hiding the console window. At startup it resolves its own executable path via std::env::current_exe() and panics with 'unable to get exec path' if the OS cannot provide it. This is an OS-level failure to locate the running binary, not a komorebi logic error.

Source

Thrown at komorebic-no-console/src/main.rs:10

#![windows_subsystem = "windows"]

use std::io;
use std::os::windows::process::CommandExt;
use std::process::Command;

const CREATE_NO_WINDOW: u32 = 0x08000000;

fn main() -> io::Result<()> {
    let mut current_exe = std::env::current_exe().expect("unable to get exec path");
    current_exe.pop();
    let komorebic_exe = current_exe.join("komorebic.exe");

    Command::new(komorebic_exe)
        .args(std::env::args_os().skip(1))
        .creation_flags(CREATE_NO_WINDOW)
        .status()
        .map(|_| ())
}

View on GitHub (pinned to e0709f02bf)

Solutions

  1. Ensure the komorebic-no-console.exe binary exists on disk at a stable location and was not deleted/quarantined while running
  2. Reinstall or update komorebi so the binary and its sibling komorebic.exe are intact in the same directory
  3. Exclude the komorebi install directory from antivirus quarantine/cleanup
  4. If current_exe() keeps failing in your launch context, invoke komorebic.exe directly instead of the no-console wrapper

Example fix

// before (fragile path resolution in a cleaned tmp dir)
let mut current_exe = std::env::current_exe().expect("unable to get exec path");
// after
let current_exe = std::env::current_exe().unwrap_or_else(|e| {
    eprintln!("failed to resolve executable path: {e}");
    std::process::exit(1);
});
Defensive patterns

Strategy: try-catch

Validate before calling

// Rust: check the binary path before relying on the wrapper
fn exe_ok() -> bool {
    std::env::current_exe().map(|p| p.is_file()).unwrap_or(false)
      && std::env::current_exe().ok()
           .and_then(|mut p| { p.pop(); Some(p.join("komorebic.exe").is_file()) })
           .unwrap_or(false)
}

Type guard

fn resolvable_exe() -> Option<std::path::PathBuf> {
    std::env::current_exe().ok().filter(|p| p.is_file())
}

Try / catch

match std::env::current_exe() {
    Ok(exe) => run_with(exe),
    Err(e) => { eprintln!("cannot resolve exec path: {e}"); std::process::exit(1); }
}

Prevention

When it happens

Trigger: std::env::current_exe() returns Err when the executable path cannot be determined: the binary was deleted or replaced while running, it was launched from a context with no resolvable path (e.g. some service hosts, tmp-cleaned environments), or the process image was unlinked.

Common situations: Running komorebic-no-console.exe from a temp directory that antivirus or cleanup tools have wiped; launching the binary through a symlink/foucher whose target was removed; exotic process-launch environments on Windows where the image path is unavailable.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors


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