warpdotdev/warp · error · anyhow::Error

Provider '{}' must be setup for either a team or personal ac

Error message

Provider '{}' must be setup for either a team or personal account

What it means

Provider setup is ambiguous: neither --team nor --personal was passed, and this provider type is allowed in both contexts (allowed_in_team_context() and allowed_in_personal_context() both true), so the SDK cannot decide which principal the OAuth connection attaches to and errors instead of guessing.

Source

Thrown at app/src/ai/agent_sdk/provider.rs:48

impl ProviderCommandRunner {
    // This shouldn't need to be done, it's usually done as part of create
    fn setup(
        &self,
        provider_type: ProviderType,
        team: bool,
        personal: bool,
        ctx: &mut ModelContext<Self>,
    ) -> anyhow::Result<()> {
        // Construct the OAuth connect URL
        let server_url = ChannelState::server_root_url();

        let mut use_team_auth = team;
        if !team && !personal {
            if provider_type.allowed_in_team_context()
                && provider_type.allowed_in_personal_context()
            {
                return Err(anyhow::anyhow!(
                    "Provider '{}' must be setup for either a team or personal account",
                    provider_type.slug()
                ));
            }
            use_team_auth = provider_type.allowed_in_team_context();
        } else if personal {
            use_team_auth = false;
        }

        // TODO(bens): initiate the OAuth flow and use the login-less auth URL
        let slug = provider_type.slug();
        let url = if use_team_auth {
            let team_uid = match UserWorkspaces::as_ref(ctx).sole_team_uid() {
                Some(uid) => uid,
                None => {
                    return Err(anyhow::anyhow!("User is not on a team"));
                }
            };

View on GitHub (pinned to e72fd7aacb)

Solutions

  1. Pass --team to attach the provider to your team, or --personal for your user account
  2. Check `warp provider list` to see which scopes the provider supports
  3. Pass the explicit flag even when you have only one possible context — it removes the ambiguity

Example fix

# before
warp provider setup github

# after
warp provider setup github --team
Defensive patterns

Strategy: validation

Validate before calling

# Require an explicit scope in wrappers instead of relying on defaults
scope="${1:?pass --team or --personal}"
warp provider setup "$slug" "$scope"

Try / catch

out=$(warp provider setup "$slug" 2>&1) || { case "$out" in *'must be setup for either a team or personal'*) echo 'choose --team or --personal' >&2; exit 1;; *) echo "$out" >&2; exit 1;; esac; }

Prevention

When it happens

Trigger: `warp provider setup <slug>` with no scope flag for a provider that supports both team and personal contexts.

Common situations: Copy-pasting a setup command from docs that omit the scope; new provider integrations where the user does not know which scope they need; wrappers that forward flags verbatim and drop the scope.

Related errors


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