openai/codex · error · anyhow::Error

pid-managed updater loop is unsupported on this platform

Error message

pid-managed updater loop is unsupported on this platform

What it means

update_loop::run has two cfg-gated bodies. The Unix implementation installs a SIGTERM handler, downloads the installer, and re-execs the managed binary; the cfg(not(unix)) stub exists so the crate compiles on Windows and immediately bails with this message. It fires when the pid-managed updater loop (the daemon's pid-update-loop entry) is started on a non-Unix platform.

Source

Thrown at codex-rs/app-server-daemon/src/update_loop.rs:84

        ClientRouteClass::Other,
    );
    if sleep_or_terminate(INITIAL_UPDATE_DELAY, &mut terminate).await {
        return Ok(());
    }
    loop {
        match update_once(&http, &running_updater_identity, &mut terminate).await {
            Ok(UpdateLoopControl::Continue) | Err(_) => {}
            Ok(UpdateLoopControl::Stop) => return Ok(()),
        }
        if sleep_or_terminate(UPDATE_INTERVAL, &mut terminate).await {
            return Ok(());
        }
    }
}

#[cfg(not(unix))]
pub(crate) async fn run(_http_client_factory: HttpClientFactory) -> Result<()> {
    bail!("pid-managed updater loop is unsupported on this platform")
}

#[cfg(unix)]
async fn sleep_or_terminate(duration: Duration, terminate: &mut Signal) -> bool {
    tokio::select! {
        _ = sleep(duration) => false,
        _ = terminate.recv() => true,
    }
}

#[cfg(unix)]
enum UpdateLoopControl {
    Continue,
    Stop,
}

#[cfg(unix)]
async fn update_once(

View on GitHub (pinned to 339751715c)

Solutions

Run the pid-managed updater loop only on macOS or Linux; on Windows use the platform-supported update path instead.
If you own the call site, gate it with #[cfg(unix)] so Windows builds never reach the stub.
If Windows support is required, implement the loop with Windows primitives (job objects, console control handlers); the bail exists because the Unix signal-plus-exec design does not translate.

Example fix

// before
let handle = tokio::spawn(run_updater(http)); // reaches the stub on Windows

// after
#[cfg(unix)]
let handle = tokio::spawn(run_updater(http));
#[cfg(not(unix))]
let handle = std::future::ready(Ok(())); // pid-managed updater is Unix-only

Defensive patterns

Strategy: validation

Validate before calling

if !cfg!(unix) {
    // The pid-managed updater loop is Unix-only; skip instead of erroring.
    return Ok(());
}
update_loop::run(http).await

Try / catch

if let Err(err) = update_loop::run(http).await {
    if err.to_string().contains("unsupported on this platform") {
        tracing::info!("skipping pid-managed updater on this platform");
        return Ok(());
    }
    return Err(err);
}

Prevention

Gate daemon updater entry points with #[cfg(unix)] at CLI dispatch level, not at the innermost call.
Mark pid-update-loop as Unix-only in CI matrices and skip its tests with cfg assertions.
When adding Unix-specific machinery (signals, exec), add matching cfg gates at every consumer.

When it happens

Trigger: Building or running app-server-daemon on Windows (cfg(not(unix))) and reaching any code path that calls update_loop::run, that is, launching the pid-managed update loop subcommand.

Common situations: CI matrices that compile and exercise the daemon on windows-latest; developers on Windows trying the daemon workflow; cross-platform refactors that compile fine but invoke Unix-only functionality.

Related errors

AI-assisted analysis of openai/codex@339751715c (2026-08-25). Data as JSON: /api/errors/5b4aee0cb07abc53. Report an issue: GitHub.