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
- Ensure the komorebic-no-console.exe binary exists on disk at a stable location and was not deleted/quarantined while running
- Reinstall or update komorebi so the binary and its sibling komorebic.exe are intact in the same directory
- Exclude the komorebi install directory from antivirus quarantine/cleanup
- 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
- Keep komorebi binaries in a stable install dir (scoop/cargo) not temp folders
- Exclude the install directory from antivirus/cleanup tools
- Verify komorebic.exe and komorebic-no-console.exe are co-located after updates
- Prefer invoking komorebic.exe directly if your launch context hides the image path
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
- could not subscribe to komorebi notifications
- no home directory found
- there is no home directory
- $Env:KOMOREBI_CONFIG_HOME is set to '{home_path}', which is
- there is no local data directory
AI-assisted analysis of LGUG2Z/komorebi@e0709f02bf (2026-09-06).
Data as JSON: /api/errors/3cf79acd46a4c195.
Report an issue: GitHub.