openai/codex · warning · std::io::Error

remote control enrollment is waiting for a ChatGPT account i

Error message

remote control enrollment is waiting for a ChatGPT account id

What it means

The loaded auth is ChatGPT-backed but carries no account id: auth.get_account_id() returns None even after the one internal reload, so constructing RemoteControlConnectionAuth fails. The error deliberately uses ErrorKind::WouldBlock — enrollment is still in flight and the account id is expected to appear, so callers should treat this as 'not ready yet' rather than a hard failure.

Source

Thrown at codex-rs/app-server-transport/src/transport/remote_control/auth.rs:74

        if auth.get_account_id().is_none() && !reloaded {
            auth_manager.reload().await;
            reloaded = true;
            continue;
        }
        break auth;
    };

    if !auth.uses_codex_backend() {
        return Err(io::Error::new(
            ErrorKind::PermissionDenied,
            "remote control requires ChatGPT authentication; API key auth is not supported",
        ));
    }

    Ok(RemoteControlConnectionAuth {
        auth_provider: codex_model_provider::auth_provider_from_auth(&auth),
        account_id: auth.get_account_id().ok_or_else(|| {
            io::Error::new(
                ErrorKind::WouldBlock,
                "remote control enrollment is waiting for a ChatGPT account id",
            )
        })?,
    })
}

pub(super) async fn recover_remote_control_auth(
    auth_recovery: &mut UnauthorizedRecovery,
    auth_change_rx: &mut watch::Receiver<u64>,
) -> bool {
    if !auth_recovery.has_next() {
        return false;
    }

    let mode = auth_recovery.mode_name();
    let step = auth_recovery.step_name();
    let auth_change_revision_before_recovery = *auth_change_rx.borrow();

View on GitHub (pinned to 339751715c)

Solutions

Retry after a short delay — WouldBlock signals the id should appear once enrollment completes
If it never appears, re-run codex login to force a fresh token with account claims
Check auth.json for the account id field to confirm whether the claim exists at all
Re-run enrollment so the server issues an account-id-bearing token

Example fix

// before
let auth = load_remote_control_auth(&auth_manager).await?;
// Err(WouldBlock): enrollment is waiting for a ChatGPT account id

// after
let auth = loop {
    match load_remote_control_auth(&auth_manager).await {
        Ok(auth) => break auth,
        Err(e) if e.kind() == std::io::ErrorKind::WouldBlock => {
            tokio::time::sleep(std::time::Duration::from_secs(2)).await;
        }
        Err(e) => return Err(e),
    }
};

Defensive patterns

Strategy: retry

Validate before calling

let missing_account_id = auth_manager
    .auth()
    .await
    .map(|a| a.get_account_id().is_none())
    .unwrap_or(true);
if missing_account_id {
    // defer the remote-control call until enrollment supplies the account id
}

Try / catch

Branch on e.kind() == ErrorKind::WouldBlock specifically and re-enter the flow after a bounded backoff (e.g. 5 attempts, 2s apart); propagate every other kind immediately.

Prevention

Show a 'finishing sign-in' state for WouldBlock instead of an error toast
Do not cache the failure — the next attempt can succeed once claims land
After login, wait on the auth-change watch channel before invoking enrollment

When it happens

Trigger: Building remote-control auth during start_pairing, pairing_status, enroll_pairing_server, refresh_pairing_enrollment, or client management when the login is ChatGPT-backed but its stored token does not yet expose a usable account id (fresh token not fully populated, account claim absent).

Common situations: Immediately after first login or a token refresh, before the account-id claim lands in auth.json; racing enrollment right after completing login in a UI; workspaces whose account id arrives only in a later token version.

Related errors

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