xai-org/grok-build · error

Failed to get cwd: {e}

Error message

Failed to get cwd: {e}

What it means

materialize_startup reads the process working directory with std::env::current_dir() to resolve the session-startup plan. If the OS call fails (typically ENOENT), the error is wrapped as 'Failed to get cwd' and startup aborts, because every path/session resolution needs a valid cwd.

Source

Thrown at crates/codegen/xai-grok-pager/src/app/session_startup.rs:809

///
/// Agent `session/new` rejects non-UUID `_meta.sessionId`; fail fast here so
/// CLI users get a clear error before ACP.
pub fn ensure_session_id_available(session_id: &str, cwd: &str) -> anyhow::Result<()> {
    if uuid::Uuid::try_parse(session_id).is_err() {
        anyhow::bail!("Error: --session-id must be a valid UUID (got '{session_id}').");
    }
    if xai_grok_shell::session::persistence::session_exists_for_cwd(session_id, cwd) {
        anyhow::bail!("Error: Session ID {session_id} is already in use.");
    }
    Ok(())
}
/// Materialize CLI intent into a concrete startup plan (I/O + remote restore).
pub async fn materialize_startup(
    ctx: MaterializeCtx,
    intent: SessionStartupIntent,
) -> anyhow::Result<MaterializedStartup> {
    let cwd = std::env::current_dir()
        .map_err(|e| anyhow::anyhow!("Failed to get cwd: {e}"))?
        .to_string_lossy()
        .to_string();
    materialize_startup_for_cwd(ctx, intent, &cwd).await
}
/// Same as [`materialize_startup`] but with an explicit process cwd (tests, headless).
pub async fn materialize_startup_for_cwd(
    ctx: MaterializeCtx,
    intent: SessionStartupIntent,
    cwd: &str,
) -> anyhow::Result<MaterializedStartup> {
    if ctx.chat_mode && matches!(intent, SessionStartupIntent::ForkFrom { .. }) {
        anyhow::bail!("{CHAT_MODE_FORK_CONFLICT}");
    }
    match intent {
        SessionStartupIntent::NewAuto => Ok(MaterializedStartup::NewAuto),
        SessionStartupIntent::NewWithId { session_id } => {
            if !ctx.has_worktree {
                ensure_session_id_available(&session_id, cwd)?;

View on GitHub (pinned to bc7f02eddd)

Solutions

1. cd back to an existing directory and relaunch grok
2. Recreate the deleted directory if the shell still points at it (mkdir -p)
3. Check the filesystem/mount is still available (especially network/WSL mounts)
4. Prefer launching grok from a stable, existing absolute path

Example fix

// before: shell cwd was deleted
$ rm -rf ~/old-project  # while grok runs here
// after: return to a live directory first
$ cd ~/new-project && grok resume

// verify the cwd is still reachable before materializing startup
fn cwd_alive() -> bool {
    std::env::current_dir().is_ok()
}

match materialize_startup(ctx, intent).await {
    Err(e) if e.to_string().starts_with("Failed to get cwd:") => {
        eprintln!("working directory vanished; cd to a valid dir and retry");
        std::env::set_current_dir("/").ok();
    }
    other => other.map(|_| ()),
}

When it happens

Trigger: Calling materialize_startup after the process's working directory has been deleted or made unreachable (e.g. the directory was removed or renamed while the process ran, or on a network filesystem that dropped).

Common situations: Deleting or renaming the project directory in another shell while grok runs inside it; container/WSL mounts disappearing; running the binary after a tmpdir cleanup removed its cwd.

Related errors

• Failed to set working directory to {:?}: {}
• overlay mount delegation not supported by this delegate
• overlay unmount delegation not supported by this delegate
• failed to create BTRFS snapshot from {} to {}: {}
• refusing to delete pre-existing snapshot {}: outside grok-ma

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