warpdotdev/warp · error

Timed out establishing IAP access to warp-server.

Error message

Timed out establishing IAP access to warp-server.

What it means

On staging, warp-server is fronted by Identity-Aware Proxy; before dispatching any authed command the CLI calls IapManager.ensure_access to establish an IAP token. If the manager emits AccessUnavailable — the token could not be obtained within its window — the command aborts with this fatal error. It is an environment/access problem, not a credentials-format problem.

Source

Thrown at app/src/ai/agent_sdk/mod.rs:1663

            return;
        }
        match event {
            IapManagerEvent::StateChanged
                if IapManager::handle(ctx).as_ref(ctx).has_valid_token() =>
            {
                handled = true;
                authenticate_and_dispatch(
                    ctx,
                    command.clone(),
                    global_options.clone(),
                    authentication.clone(),
                    parent_span.clone(),
                );
            }
            IapManagerEvent::AccessUnavailable => {
                handled = true;
                report_fatal_error(
                    anyhow::anyhow!("Timed out establishing IAP access to warp-server."),
                    ctx,
                );
            }
            _ => {}
        }
    });

    iap.update(ctx, |manager, ctx| manager.ensure_access(ctx));

    Ok(())
}

/// Subscribes to auth events, authenticates, and dispatches the command once
/// auth completes. Assumes IAP access (if applicable) is already established.
fn authenticate_and_dispatch(
    ctx: &mut AppContext,
    command: CliCommand,
    global_options: GlobalOptions,

View on GitHub (pinned to e72fd7aacb)

Solutions

1. Check network/proxy/VPN access to the staging IAP endpoint and retry
2. Re-run `warp login` so fresh SSO credentials are available for the IAP flow
3. Verify SERVER_ROOT_URL points at the environment you actually intend (staging vs production mix-ups are common)
4. If it persists, check staging server health before retrying

# Connectivity preflight to the staging front door before long commands
curl -fsS --max-time 10 "$SERVER_ROOT_URL" >/dev/null || { echo 'staging endpoint unreachable; check VPN/proxy' >&2; exit 1; }

for i in 1 2 3; do
  out=$(warp agent list 2>&1) && { echo "$out"; exit 0; }
  case "$out" in *'Timed out establishing IAP access'*) wait $((i * 10));; *) echo "$out" >&2; exit 1;; esac
done
echo 'IAP access repeatedly unavailable' >&2; exit 1

When it happens

Trigger: Any auth-required command against a staging server_url with IAP enabled, where IAP token acquisition fails: network to the IAP endpoint blocked, SSO context rejected or absent, or the IAP handshake timing out.

Common situations: Corporate proxy/firewall blocking the IAP domain; VPN split-tunneling dropping the staging endpoint; staging-side outages; accidentally targeting the staging SERVER_ROOT_URL from a production workflow.

Understand the failure class

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

Related errors

• Timed out refreshing team metadata
• Failed to fetch images: {}
• Timed out waiting for Warp Drive to sync
• Failed to fetch images: {err}
• Error polling OAuth status: {err}

AI-assisted analysis of warpdotdev/warp@e72fd7aacb (2026-08-16). Data as JSON: /api/errors/971788ade005987d. Report an issue: GitHub.