xai-org/grok-build · info

Authentication cancelled

Error message

Authentication cancelled

What it means

This error is thrown in the ACP agent's `authenticate` flow when the interactive authentication request is cancelled while awaiting the auth flow. The agent runs the auth flow (`run_auth_flow_with_stderr_bridge`) inside a `tokio::select!` alongside a cancellation token obtained from `interactive_auth.begin`; when the cancellation future fires first, the code sets `cancelled = true` and returns this anyhow error instead of the auth result. It is a deliberate control-flow signal, not a protocol or credential failure — it means the client (or a timeout/shutdown) aborted authentication before it completed.

Source

Thrown at crates/codegen/xai-grok-shell/src/agent/mvp_agent/acp_agent.rs:820

                let auth_result = if !auth_meta.headless {
                    let (url_tx, url_rx) = tokio::sync::oneshot::channel();
                    let (code_tx, code_rx) = tokio::sync::mpsc::channel(1);
                    let (cancel, _guard) = self
                        .interactive_auth
                        .begin(
                            Some(
                                crate::auth::single_flight::AttemptChannels::new(
                                    code_tx,
                                    url_rx,
                                ),
                            ),
                            client_seq,
                        );
                    tokio::select! {
                        biased;
                        _ = cancel.cancelled() => {
                            cancelled = true;
                            Err(anyhow::anyhow!("Authentication cancelled"))
                        }
                        r = crate::auth::run_auth_flow_with_stderr_bridge(
                            &self.auth_manager,
                            grok_ctx,
                            crate::auth::AuthChannels {
                                url_tx: Some(url_tx),
                                code_rx,
                            },
                            auth_meta.reauth,
                            auth_meta.force_interactive,
                            login_override,
                        ) => r,
                    }
                } else {
                    let (cancel, _guard) = self.interactive_auth.begin(None, client_seq);
                    tokio::select! {
                        biased;
                        _ = cancel.cancelled() => {

View on GitHub (pinned to bc7f02eddd)

Solutions

  1. Have the caller treat 'Authentication cancelled' as an expected, benign outcome (map it to a cancelled/aborted RPC status rather than a hard failure) and simply re-issue `authenticate` when the user is ready to log in
  2. Check the client side for premature aborts: raise the client-side timeout for the auth request and ensure the transport is not closed while the auth flow is in flight
  3. Avoid issuing a second `authenticate` call while one is pending; cancel the first deliberately or wait for it to finish
  4. If auth hangs indefinitely, verify the auth flow can reach its URL/redirect handler (network, browser availability) so it completes before anything cancels it

Example fix

// before
match agent.authenticate(method).await {
    Err(e) if e.to_string().contains("Authentication cancelled") => panic!("auth failed: {e}"),
    r => r?,
}
// after
match agent.authenticate(method).await {
    Err(e) if e.to_string().contains("Authentication cancelled") => {
        tracing::info!("auth cancelled by client; retry when user initiates login");
        return Ok(()); // benign cancellation, not an auth failure
    }
    r => r?,
}
Defensive patterns

Strategy: try-catch

Try / catch

match agent.authenticate(method).await {
    Err(e) if e.to_string().contains("Authentication cancelled") => {
        // expected cancellation — surface as user-aborted, retry on demand
        return Err(AuthError::Cancelled);
    }
    Err(e) => return Err(AuthError::Other(e)),
    Ok(method) => Ok(method),
}

Prevention

When it happens

Trigger: Calling the ACP `authenticate` RPC with an `interactive_auth` session and issuing a cancel (client aborts the request, disconnects, or a supervisor cancels the task) while `run_auth_flow_with_stderr_bridge` is still waiting on the browser/URL-based auth flow.

Common situations: User closes the auth browser window or presses Ctrl-C on the client before completing OAuth; IDE/ACP client times out a slow auth request; the agent task is cancelled during shutdown while authentication is pending; a second auth request supersedes an in-flight one and cancels the first session.

Understand the failure class

Related errors


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