warpdotdev/warp · error

Auth secret type {:?} is not supported via the harness FTUX

Error message

Auth secret type {:?} is not supported via the harness FTUX flow

What it means

build_managed_secret_value only constructs ManagedSecretValue for the concretely-shaped harness secret types (Anthropic/Bedrock/OpenAI API keys, etc.). ManagedSecretType::RawValue and ManagedSecretType::Dotenvx are explicitly rejected because the harness FTUX (first-time UX) flow has no form definition for them.

Source

Thrown at app/src/ai/auth_secret_types.rs:93

            };
            Ok(ManagedSecretValue::anthropic_bedrock_access_key(
                field_values[0].clone(),
                field_values[1].clone(),
                session_token,
                field_values[3].clone(),
            ))
        }
        ManagedSecretType::OpenaiApiKey => {
            let base_url = field_values
                .get(1)
                .map(|s| s.trim().to_owned())
                .filter(|s| !s.is_empty());
            Ok(ManagedSecretValue::openai_api_key(
                field_values[0].clone(),
                base_url,
            ))
        }
        ManagedSecretType::RawValue | ManagedSecretType::Dotenvx => Err(anyhow!(
            "Auth secret type {:?} is not supported via the harness FTUX flow",
            info.secret_type
        )),
    }
}

static CODEX_AUTH_SECRET_TYPES: [AuthSecretTypeInfo; 1] = [AuthSecretTypeInfo {
    display_name: "OpenAI API Key",
    secret_type: ManagedSecretType::OpenaiApiKey,
    learn_more_url: CODEX_LEARN_MORE_URL,
    fields: &[
        AuthSecretTypeField {
            label: "OPENAI_API_KEY",
            placeholder: Some("sk-..."),
            optional: false,
            sensitive: true,
        },
        AuthSecretTypeField {

View on GitHub (pinned to e72fd7aacb)

Solutions

  1. Drive the FTUX picker from curated static lists (e.g. CODEX_AUTH_SECRET_TYPES) rather than enumerating ManagedSecretType
  2. Match exhaustively on ManagedSecretType before calling and route RawValue/Dotenvx to their own flows
  3. When adding a secret type, extend the match arm and the curated list together

Example fix

// before
for info in all_secret_type_infos() {
    let v = build_managed_secret_value(&info, &values)?; // may hit RawValue/Dotenvx
}

// after
fn ftux_capable(info: &AuthSecretTypeInfo) -> bool {
    !matches!(
        info.secret_type,
        ManagedSecretType::RawValue | ManagedSecretType::Dotenvx
    )
}
for info in all_secret_type_infos().into_iter().filter(|i| ftux_capable(i)) {
    let v = build_managed_secret_value(&info, &values)?;
}
Defensive patterns

Strategy: type-guard

Type guard

fn supports_ftux_flow(t: ManagedSecretType) -> bool {
    !matches!(
        t,
        ManagedSecretType::RawValue | ManagedSecretType::Dotenvx
    )
}

Try / catch

match build_managed_secret_value(&info, &values) {
    Err(e) if e.to_string().contains("not supported via the harness FTUX flow") => {
        route_to_native_flow(info.secret_type); // dotenvx/raw editor instead
    }
    r => r?,
}

Prevention

When it happens

Trigger: Routing a secret whose info.secret_type is ManagedSecretType::RawValue or ManagedSecretType::Dotenvx into build_managed_secret_value - e.g. enumerating all ManagedSecretType variants generically and feeding each into the FTUX flow (auth_secret_types.rs:93-96).

Common situations: New ManagedSecretType variants added without deciding FTUX support; code that builds the type list from a server enum instead of the curated CODEX_AUTH_SECRET_TYPES/CLAUDE-style static lists.

Related errors


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