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
- Drive the FTUX picker from curated static lists (e.g. CODEX_AUTH_SECRET_TYPES) rather than enumerating ManagedSecretType
- Match exhaustively on ManagedSecretType before calling and route RawValue/Dotenvx to their own flows
- 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
- Populate FTUX pickers from curated static lists (e.g. CODEX_AUTH_SECRET_TYPES), not the full enum
- Handle every ManagedSecretType variant explicitly when new types are added
- Keep the match arm in build_managed_secret_value and the UI type list in sync
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
- Expected {} field values, got {}
- invalid value 'secret'
- Field '{}' is required
- STS AssumeRoleWithWebIdentity failed: {detail}
- Failed to fetch images
AI-assisted analysis of warpdotdev/warp@e72fd7aacb (2026-08-16).
Data as JSON: /api/errors/3d0a15c324c427ea.
Report an issue: GitHub.