cannot rename locked executable {}: {e} Close all running gr

Error message

cannot rename locked executable {}: {e}
Close all running grok sessions and retry.

What it means

On Windows the running executable is locked, so replacing it requires renaming the old file aside first. This error is raised after exhausting retry attempts to rename the locked destination executable, telling the user another process still holds it open. It is a deliberate, user-actionable error rather than a raw OS error.

Source

Thrown at crates/codegen/xai-grok-update/src/auto_update.rs:2134

    let mut rename_result = tokio::fs::rename(dest, &aside).await;
    // Pid reuse can collide a diverted name with a dead updater's
    // still-locked leftover, and a racer can occupy a just-checked-free
    // .old; a fresh unique sibling clears both tails (3 attempts total).
    for _ in 0..2 {
        match &rename_result {
            Err(e) if matches!(e.raw_os_error(), Some(32) | Some(5)) => {
                tracing::debug!(
                    "rename aside to {} failed; retrying with a fresh name: {e}",
                    aside.display()
                );
                aside = unique_temp_sibling(&old, "old");
                rename_result = tokio::fs::rename(dest, &aside).await;
            }
            _ => break,
        }
    }
    rename_result.map_err(|e| {
        anyhow::anyhow!(
            "cannot rename locked executable {}: {e}\n\
             Close all running grok sessions and retry.",
            dest.display(),
        )
    })?;
    match tokio::fs::copy(src, dest).await {
        Ok(_) => Ok(()),
        Err(e) => {
            // Rollback: restore the old binary so the install isn't broken.
            let _ = tokio::fs::rename(&aside, dest).await;
            Err(e.into())
        }
    }
}

/// Best-effort removal of `<exe>.old` plus the unique
/// `<exe>.old.{pid}-{seq}.old` asides accumulated by prior update cycles.
/// Locked ones (still-running images) survive and are collected by a later

View on GitHub (pinned to bc7f02eddd)

Solutions

Close all running grok sessions/processes and retry the update
Check Task Manager for lingering grok.exe processes and kill them, then retry
Temporarily disable antivirus real-time scanning of the install directory if it holds the file lock
Reboot to release all locks, then run the update

Defensive patterns

Strategy: retry

Try / catch

match update.run().await {
    Err(e) if e.to_string().contains("cannot rename locked executable") => {
        eprintln!("close all grok sessions and run the update again");
    }
    result => result?,
}

Prevention

Exit all grok processes before self-updating on Windows
Check Task Manager for lingering grok.exe processes before updating
Exclude the install directory from antivirus scanning to avoid transient locks
Retry the update after a reboot if locks persist

When it happens

Trigger: tokio::fs::rename(dest, aside) failing repeatedly during a self-update because grok.exe (the destination) is locked by a running process; the loop retries/moves aside and finally gives up with this message.

Common situations: Multiple grok sessions (or an attached editor/terminal with the binary memory-mapped) running during update; antivirus scanning the binary holding a handle; a hung background grok process on Windows.

Related errors

AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31). Data as JSON: /api/errors/d1d627157799f719. Report an issue: GitHub.