Codewhale-owned xAI OAuth storage owner is not the current u

Error message

Codewhale-owned xAI OAuth storage owner is not the current user

What it means

After securing a windows handle, verify_windows_owner_only_handle re-reads the security descriptor and requires the owner SID to equal the current user's SID. This catches filesystems that drop owners (FAT32/exFAT return a NULL owner) and files created elevated (owned by Administrators), so tokens never live in storage another principal effectively controls.

Source

Thrown at crates/config/src/xai_credentials.rs:1365

    // SAFETY: the handle remains valid and all output pointers are writable.
    let result = unsafe {
        GetSecurityInfo(
            file.as_raw_handle(),
            SE_FILE_OBJECT,
            OWNER_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION,
            &mut owner,
            std::ptr::null_mut(),
            &mut dacl,
            std::ptr::null_mut(),
            &mut descriptor,
        )
    };
    if result != ERROR_SUCCESS {
        return Err(std::io::Error::from_raw_os_error(result as i32))
            .context("reading Codewhale-owned xAI OAuth security descriptor");
    }
    let _descriptor = WindowsLocalAllocation(descriptor.cast());
    anyhow::ensure!(
        !owner.is_null() && unsafe { EqualSid(owner, user.sid()) } != 0,
        "Codewhale-owned xAI OAuth storage owner is not the current user"
    );
    anyhow::ensure!(
        !dacl.is_null(),
        "Codewhale-owned xAI OAuth storage must have an owner-only DACL"
    );
    let mut count = 0;
    let mut entries: *mut EXPLICIT_ACCESS_W = std::ptr::null_mut();
    // SAFETY: `dacl` belongs to the live descriptor; Windows allocates the
    // returned entry array, released by the guard below.
    let result = unsafe { GetExplicitEntriesFromAclW(dacl, &mut count, &mut entries) };
    if result != ERROR_SUCCESS {
        return Err(std::io::Error::from_raw_os_error(result as i32))
            .context("reading Codewhale-owned xAI OAuth DACL entries");
    }
    let _entries = WindowsLocalAllocation(entries.cast());
    anyhow::ensure!(

View on GitHub (pinned to 8880682c63)

Solutions

Reset ownership: takeown /F <path> /R /D Y then icacls <path> /setowner "%USERNAME%" /T, or delete $CODEWHALE_HOME/credentials and log in again as the normal user
Keep $CODEWHALE_HOME on NTFS (or ReFS) where owner SIDs exist
Never run the first codewhale auth elevated

Example fix

:: before (credentials created while elevated)
:: after
takeown /F "%USERPROFILE%\.codewhale" /R /D Y
icacls "%USERPROFILE%\.codewhale" /setowner "%USERNAME%" /T
codewhale auth xai-device

Defensive patterns

Strategy: retry

Try / catch

match open_store_and_login() {
    Ok(v) => v,
    Err(e) if e.to_string().contains("storage owner is not the current user") => {
        // remediate once: takeown + icacls, or delete + re-login, then retry
        takeown_and_reset_owner(&home)?;
        open_store_and_login()?
    }
    Err(e) => return Err(e),
}

Prevention

Run the first login as the normal user, never elevated
Keep CODEWHALE_HOME on NTFS where owner SIDs exist
After any elevated mishap, reset ownership before the next login

When it happens

Trigger: First login run elevated so the credentials are owned by Administrators, then used non-elevated; $CODEWHALE_HOME on FAT32/exFAT where GetSecurityInfo yields a NULL owner; ownership changed by takeown/icacls or corporate scripts.

Common situations: Run-as-admin first logins; USB/exFAT-redirected home directories; enterprise scripts resetting ownership.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@8880682c63 (2026-08-16). Data as JSON: /api/errors/f063fa4d58bb95a8. Report an issue: GitHub.