What causes "timed out after {duration:?}" in jdx/mise?

Increase the timeout: raise the relevant mise timeout setting or task timeout value.

timed out after {duration:?}

Error message

timed out after {duration:?}

What it means

A spawned child process exceeded the configured timeout and was killed; cmd.rs reports `timed out after <duration>` instead of the process's real exit status. The timeout_guard recorded the timeout before on_error ran, so mise replaces the non-zero-exit reporting with the timeout explanation.

Source

Thrown at src/cmd.rs:1038

                        // it again would just be a redundant kill.
                        debug!("Received signal {sig}, forwarding to {id}");
                        let _ = nix::sys::signal::kill(pid, nix_sig);
                    }
                }
            }
        }
        // Removed after rx loop drains (not inside ExitStatus arm) so kill_all
        // can still reach this PID while output is being processed.
        RUNNING_PIDS.lock().unwrap().remove(&id);
        if let Some(g) = &timeout_guard {
            g.cancel();
        }

        let status = status.unwrap();

        if !status.success() {
            if let Some(duration) = timeout_guard.as_ref().and_then(|g| g.timed_out()) {
                bail!("timed out after {duration:?}");
            }
            self.on_error(
                failure_output.map_or_else(Vec::new, FailureOutputTail::into_output),
                status,
            )?;
        }

        Ok(())
    }

    pub(crate) async fn execute_async(self) -> Result<()> {
        self.execute_async_with_cancel_check(|| false).await
    }

    /// Execute a command while preventing cancellation from being lost between
    /// the pre-spawn check and PID registration.
    pub(crate) async fn execute_async_with_cancel_check(
        mut self,

View on GitHub (pinned to afd2eddd3a)

Solutions

Increase the timeout: raise the relevant mise timeout setting or task timeout value.
Fix the underlying slowness (network, dependency resolution) so the command finishes in time.
Make the command non-interactive (CI=1, flags like --yes) so it never hangs on prompts.
If the command legitimately needs unbounded time, remove/disable the timeout for it.

Example fix

// before (mise.toml)
[tools]
node = '22'
[settings]
task_timeout = '30s'
# long build: timed out after 30s
// after
[settings]
task_timeout = '10m'

Defensive patterns

Strategy: try-catch

Validate before calling

# estimate worst-case runtime before enabling the timeout
start=$(date +%s); command; echo $(( $(date +%s) - start ))s

Try / catch

if mise run build 2>&1 | grep -q 'timed out after'; then rerun_with_higher_timeout; fi

Prevention

Set timeouts with generous headroom (2-3x your slowest environment, e.g. CI).
Make commands non-interactive so they never block on prompts.
Monitor task durations and tune timeouts from real measurements.

When it happens

Trigger: Executing any command through mise's Cmd::execute (task run, hooks, postinstall scripts) with a timeout configured (e.g. mise settings timeout / task timeout), where the process runs longer than the limit and fails as a result of being killed.

Common situations: Slow network downloads in postinstall scripts behind a proxy; long-running builds with a too-tight task timeout; a process hanging on stdin waiting for input; CI machines slower than dev machines.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/cd36682392c281ea. Report an issue: GitHub.