The error message generated when failing to remove a cache file is not sanitized, which violates the general rule to prevent escape sequence injection in terminal output. Additionally, using path.exists() followed by remove_file introduces a TOCTOU (time-of-check to time-of-use) race condition. It is more robust to attempt the removal directly and handle the NotFound error case. Please acknowledge and document potential TOCTOU race conditions as a known limitation if a full mitigation (e.g., using openat(O_NOFOLLOW)) is considered out of scope.

fn clear_token_caches() -> Result<Vec<PathBuf>, GwsError> {
    let mut removed = Vec::new();
    for path in token_cache_paths() {
        match std::fs::remove_file(&path) {
            Ok(_) => removed.push(path),
            Err(e) if e.kind() == std::io::ErrorKind::NotFound => {}
            Err(e) => {
                return Err(GwsError::Validation(crate::output::sanitize_for_terminal(
                    &format!("Failed to remove {}: {e}", path.display()),
                )));
            }
        }
    }
    Ok(removed)
}

This loop lacks error string sanitization and contains a TOCTOU race condition. Following the pattern suggested for the clear_token_caches helper, you should sanitize the error message and handle the NotFound case explicitly instead of checking for existence beforehand. Note that potential TOCTOU race conditions should be acknowledged as a known limitation if full mitigation is out of scope.

        match std::fs::remove_file(path) {
            Ok(_) => removed.push(path.display().to_string()),
            Err(e) if e.kind() == std::io::ErrorKind::NotFound => {}
            Err(e) => {
                return Err(GwsError::Validation(crate::output::sanitize_for_terminal(
                    &format!("Failed to remove {}: {e}", path.display()),
                )));
            }
        }

Using the ? operator here causes the entire login command to fail if clearing the token caches fails (e.g., due to a permission issue). However, at this point, the new credentials have already been successfully encrypted and saved to disk (lines 668-669). Failing the command here prevents the success message and account details from being printed (lines 676-687), which leads to a confusing user experience where the tool reports failure despite the authentication actually succeeding.

Since clearing the cache is a secondary cleanup step, it is better to handle any errors gracefully (e.g., by logging a warning) so that the login process can complete successfully and the user is informed of their current status.

    if let Err(e) = clear_token_caches() {
        eprintln!("Warning: {e}");
    }