wezterm/wezterm · critical

failed to re-exec: {:?}

Error message

failed to re-exec: {:?}

What it means

When wezterm-mux-server runs with --daemonize on Unix it forks, then re-executes its own binary (std::env::current_exe(), passing --pid-file-fd) to reset the async runtime. Command::exec() replaces the process and only returns on failure, so reaching this line means exec itself failed; the io::Error is wrapped as 'failed to re-exec: {err:?}'. The daemon cannot start.

Source

Thrown at wezterm-mux-server/src/main.rs:184

            cmd.creation_flags(winapi::um::winbase::DETACHED_PROCESS);
            let child = cmd.spawn();
            drop(child);
            return Ok(());
        }

        #[cfg(unix)]
        {
            use std::os::unix::process::CommandExt;
            if let Some(mask) = umask::UmaskSaver::saved_umask() {
                unsafe {
                    cmd.pre_exec(move || {
                        libc::umask(mask);
                        Ok(())
                    });
                }
            }

            return Err(anyhow::anyhow!("failed to re-exec: {:?}", cmd.exec()));
        }
    }

    // Remove some environment variables that aren't super helpful or
    // that are potentially misleading when we're starting up the
    // server.
    // We may potentially want to look into starting/registering
    // a session of some kind here as well in the future.
    for name in &[
        "OLDPWD",
        "PWD",
        "SHLVL",
        "WEZTERM_PANE",
        "WEZTERM_UNIX_SOCKET",
        "_",
    ] {
        std::env::remove_var(name);
    }

View on GitHub (pinned to 3ff7522b96)

Solutions

1. Read the wrapped io::Error: ENOENT/EACCES mean the binary vanished or is not executable — reinstall/rebuild wezterm and start again
2. Install wezterm to a stable path and launch the daemon from there instead of a throwaway build dir
3. Run without --daemonize once to see the error directly and confirm exec works
4. If the error is ENOMEM or a sandbox denial, raise resource limits / adjust the seccomp or container profile to allow execve

Example fix

# before: daemonize straight out of a rebuildable dir
/tmp/wezterm-build/target/debug/wezterm-mux-server --daemonize .  # -> failed to re-exec

# after: install to a stable path first
cp target/release/wezterm /usr/local/bin/ && /usr/local/bin/wezterm-mux-server --daemonize .

// before daemonizing, confirm we can still exec ourselves
let exe = std::env::current_exe()?;
anyhow::ensure!(exe.is_file(), "binary vanished: {}", exe.display());

This Err from main is terminal for the daemon: inspect the wrapped io::Error (ENOENT -> binary gone, EACCES -> permissions, ENOMEM -> resources); fix the install and relaunch rather than retrying in-process.

When it happens

Trigger: The binary at current_exe() no longer exists or lost execute permission between start and re-exec (replaced build artifact, nix store GC, rust target dir clobbered, package upgrade mid-run); ENOMEM or a security policy (seccomp/AppArmor) blocking execve.

Common situations: Running wezterm-mux-server out of a target/ directory that a rebuild replaced; NixOS store garbage collection removing the running version; containers with restrictive seccomp profiles; moving/renaming the install prefix.

Related errors

• failed to exec {cmd:?}: {res:?}
• {} has no parent?
• unhandled type for {name}: {:#?}
• TerminalShim::waker called!?
• fontconfig not compiled in

AI-assisted analysis of wezterm/wezterm@3ff7522b96 (2026-08-20). Data as JSON: /api/errors/6db072e80799577e. Report an issue: GitHub.