Providers Bug Fix/Feature: add Chutes API-key auth and dynamic model discovery by Veightor · Pull Request #37822 · openclaw/openclaw

Veightor · 2026-03-06T13:01:51Z

Summary

Problem: The existing Chutes provider in OpenClaw had no API key auth path (only OAuth was documented/wired), the OAuth implementation lacked proper PKCE/CSRF state validation, model discovery called a public endpoint without using or recovering from auth failures, and no dynamic model list was fetched — only a hardcoded static catalog was available.
Why it matters: Chutes offers a growing catalog of open-weight models (Qwen, DeepSeek, Mistral, GLM, Kimi, etc.) behind both OAuth and API-key auth; without a working integration, users cannot route through Chutes at all, and the available model list goes stale rapidly.
What changed: Added a chutes-api-key onboarding auth choice wired through all the relevant routing/credential tables; wrote chutes-models.ts with live GET /v1/models discovery (5-min cache, fallback to a broad static catalog), streaming-compat flag, and retry-on-401 logic; wrote chutes-oauth.ts with full PKCE generation, authorization-code exchange, token refresh, userinfo fetch, and strict OAuth state validation; added unit and flow tests for both modules.
What did NOT change: No existing auth paths were removed or modified; no upstream provider code, gateway routing, or channel logic was touched; the Chutes OAuth onboarding flow that was already in origin/main is preserved and supplemented rather than replaced.

Change Type (select all)

Bug fix (OAuth state/CSRF handling fixed; 401 retry on model discovery fixed; streaming-compat flag added to prevent parser breakage)
Feature (API-key auth path added; dynamic model discovery; broad static catalog)
Refactor
Docs
Security hardening
Chore/infra

Scope (select all touched areas)

Gateway / orchestration
Skills / tool execution
Auth / tokens (PKCE/OAuth flow, API-key credential storage, token refresh)
Memory / storage
Integrations (Chutes provider: model catalog, streaming compat, API surface)
API / contracts (AuthChoice union type extended; onboard routing updated)
UI / DX
CI/CD / infra

Linked Issue/PR

Related: Feat/chutes provider integration chutesai/openclaw#2

User-visible / Behavior Changes

A new "Chutes (API key)" option (chutes-api-key) appears in openclaw onboard alongside the existing OAuth flow.
Running openclaw onboard --auth chutes-api-key stores the key and sets the Chutes provider with the full model list.
The Chutes provider now auto-discovers all available models from the Chutes /v1/models API at startup (5-min TTL cache); if discovery fails or returns empty, it falls back to a curated static catalog of ~50 models.
Model entries include accurate contextWindow, maxTokens, and per-model pricing from the API.
Streaming responses from Chutes no longer include usage-only chunks that break the OpenAI-compatible stream parser (supportsUsageInStreaming: false compat flag).
The chutes (OAuth) onboarding path now enforces full redirect-URL paste with CSRF state validation; bare code-only pastes are rejected.

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? Yes — API keys are stored via the same upsertAuthProfile / setChutesApiKey credential pipeline used by all other providers. OAuth tokens (access + refresh) are stored via writeOAuthCredentials. No new storage location or format is introduced.
New/changed network calls? Yes — GET https://llm.chutes.ai/v1/models for model discovery at startup (respects VITEST/NODE_ENV=test guard and has a 10-second timeout + fallback). POST https://api.chutes.ai/idp/token for code exchange and refresh. GET https://api.chutes.ai/idp/userinfo for username resolution.
Command/tool execution surface changed? No
Data access scope changed? No

Risk + mitigation for network calls: Discovery endpoint is called only when a Chutes key/profile is configured, with a hard timeout and a static-catalog fallback — no user data is sent, only the Bearer token if present. On 401, it retries unauthenticated (the endpoint is public), so a stale/invalid key never blocks startup.

Risk + mitigation for token storage: Refresh tokens are stored in the existing auth-profiles store; CHUTES_CLIENT_ID / CHUTES_CLIENT_SECRET are read from env vars at refresh time, following the same pattern as other OAuth providers (MiniMax, Qwen, etc.) — no new secret-handling code paths introduced.

Repro + Verification

Environment

OS: macOS 15 (darwin 25.2.0)
Runtime/container: Node 22 / Bun (pnpm workspace)
Model/provider: Chutes (llm.chutes.ai) — OAuth and API-key paths
Integration/channel: CLI (openclaw onboard)
Relevant config (redacted): CHUTES_CLIENT_ID=<redacted>, CHUTES_API_KEY=<redacted>

Steps (API-key path)

Run openclaw onboard --auth chutes-api-key
Paste your Chutes API key when prompted
Confirm model discovery completes and the chutes provider appears in openclaw models

Steps (OAuth path)

Run openclaw onboard --auth chutes
Open the printed authorization URL in a browser, approve access
Paste the full redirect URL (including ?code=...&state=...) back into the CLI
Confirm token exchange succeeds and openclaw models lists Chutes models

Expected

Both auth paths complete without error
openclaw models lists dynamically discovered Chutes models (or the static catalog on network failure)
No streaming parse errors when sending messages

Actual

Same as expected after fixes (before: OAuth accepted bare codes with no state validation; model discovery failed silently on 401 without retry; streaming produced usage-only chunks that corrupted responses)

Evidence

Unit tests: src/agents/chutes-models.test.ts — covers static catalog, API mapping, 401 retry, compat flag
Unit tests: src/agents/chutes-oauth.test.ts — covers PKCE generation, state validation, URL/querystring parsing, CSRF rejection
Flow tests: src/agents/chutes-oauth.flow.test.ts — covers full token exchange (with userinfo), refresh (with/without new refresh token)

Human Verification (required)

Verified scenarios:
- API-key onboarding stores credential correctly and is resolved by resolveImplicitProviders
- Model discovery fetches live model list when a valid token is present
- 401 from model discovery endpoint triggers unauthenticated retry
- OAuth PKCE verifier/challenge pair validates correctly
- Pasting full redirect URL with matching state succeeds; mismatched state is rejected
- Streaming compat flag prevents usage-only chunk parser errors
Edge cases checked:
- Empty or whitespace-only API key is rejected
- Bare code paste (no state=) is rejected with a clear error
- Discovery failure (network down) falls back to static catalog without crashing
- Token refresh preserves existing refresh token when server returns an empty refresh_token
What was NOT verified:
- End-to-end agent conversation through Chutes with a live key (live API test)
- Token refresh in a long-running gateway session (refresh path tested via unit tests only)
- All ~50 static catalog models confirmed as currently available on Chutes

Compatibility / Migration

Backward compatible? Yes — existing chutes OAuth credential profiles are unchanged; only an additive API-key path and model-discovery layer are added.
Config/env changes? Yes — CHUTES_CLIENT_ID and CHUTES_CLIENT_SECRET env vars are read at OAuth refresh time (same as the existing Chutes OAuth setup; no new requirement for API-key users).
Migration needed? No — existing setups continue to work; users who previously had no Chutes config can now onboard via either path.

Failure Recovery (if this breaks)

How to disable/revert quickly: Remove the chutes provider entry from ~/.openclaw/models.json (or delete the chutes auth profile via openclaw config); the Chutes provider will not load without a key/profile.
Files/config to restore: ~/.openclaw/models.json, ~/.openclaw/agents/<id>/auth-profiles.json
Known bad symptoms to watch for:
- Startup hang > 10s on resolveImplicitProviders (would indicate the AbortSignal.timeout(10_000) is not firing — unlikely but check llm.chutes.ai reachability)
- OAuth state mismatch errors on valid callbacks (check that the redirect URL is being pasted in full)
- Models list showing only the ~50 static entries when a valid key is set (check network connectivity to llm.chutes.ai)

Risks and Mitigations

Risk: Dynamic model discovery at startup adds a network call that could slow gateway boot if llm.chutes.ai is slow.
- Mitigation: Hard 10-second AbortSignal.timeout, 5-minute in-process cache so only the first boot per run pays the cost, and immediate fallback to the static catalog on any failure.
Risk: The static model catalog may go stale as Chutes adds/removes models.
- Mitigation: Dynamic discovery overrides the static catalog whenever it succeeds; the static list is a reasonable fallback and can be updated in a follow-up PR without any auth or routing changes.
Risk: Storing clientId in the OAuth credential struct is a minor schema addition that could break deserialization if the field is later renamed.
- Mitigation: It's stored as an optional field (clientId?) on the existing OAuthCredentials shape; reading code gracefully falls back to CHUTES_CLIENT_ID env var if missing.

…nd API key auth

…atibility

…resolve conflicts Made-with: Cursor

greptile-apps · 2026-03-06T13:05:50Z

Greptile Summary

This PR adds a chutes-api-key onboarding path and dynamic model discovery for the Chutes provider, complementing the existing OAuth flow. The architecture is solid — the 5-minute TTL cache with a 10-second AbortSignal.timeout and immediate fallback to the static catalog is a clean pattern consistent with other provider integrations in the codebase.

Issues found:

Broken chutes-fast alias (src/commands/onboard-auth.config-core.ts:322): The alias resolves to "chutes/zai-org/GLM-4.7-Flash", which does not exist in CHUTES_MODEL_CATALOG. The catalog only contains GLM-4.7-TEE and GLM-4.7-FP8. Any user who selects chutes-fast will get a model-not-found error at runtime; this should be corrected to one of the two valid variants before merging.
Inconsistent setChutesApiKey signature (src/commands/onboard-auth.credentials.ts:332): The function accepts a plain string instead of the SecretInput type used by every other set*ApiKey helper in the file, and omits ApiKeyStorageOptions. This bypasses the buildApiKeyCredential helper, meaning encrypted-storage modes silently don't work for Chutes API keys.
Test mock data type mismatch (src/agents/chutes-models.test.ts): The 401-retry test feeds CHUTES_MODEL_CATALOG.slice(0, 3) (type ModelDefinitionConfig[]) as the mock API response instead of ChutesModelEntry objects. The test still passes because the mapping code tolerates missing fields, but the mock doesn't accurately represent the real API shape.

Confidence Score: 3/5

Safe to merge after fixing the broken chutes-fast alias — the alias will cause a runtime model-not-found error for users who select it.
Core logic for API-key onboarding, credential storage, and dynamic model discovery is well-structured and follows established patterns. One definite runtime bug (the chutes-fast alias pointing to a non-existent model) blocks a clean merge. The setChutesApiKey signature inconsistency is a quality issue that will cause subtle breakage if encrypted storage is ever used for Chutes keys.
src/commands/onboard-auth.config-core.ts (broken alias on line 322) and src/commands/onboard-auth.credentials.ts (inconsistent setChutesApiKey signature).

_{Last reviewed commit: 1f34bd6}

greptile-apps · 2026-03-06T13:05:53Z

+  // but init.sh uses 'chutes/' + m.id.
+
+  // Add aliases from init.sh
+  models["chutes-fast"] = { alias: "chutes/zai-org/GLM-4.7-Flash" };


chutes-fast alias references a non-existent model

"zai-org/GLM-4.7-Flash" does not exist in CHUTES_MODEL_CATALOG. The catalog only contains "zai-org/GLM-4.7-TEE" (line 216) and "zai-org/GLM-4.7-FP8" (line 378). Any user who invokes chutes-fast will get a model-not-found error at runtime. Based on the other two aliases, the likely intended model is one of those two — TEE for the TEE-attested secure variant or FP8 for the quantized variant.

Suggested change

models["chutes-fast"] = { alias: "chutes/zai-org/GLM-4.7-Flash" };

models["chutes-fast"] = { alias: "chutes/zai-org/GLM-4.7-TEE" };

Prompt To Fix With AI

This is a comment left during a code review. Path: src/commands/onboard-auth.config-core.ts Line: 322 Comment: **`chutes-fast` alias references a non-existent model** `"zai-org/GLM-4.7-Flash"` does not exist in `CHUTES_MODEL_CATALOG`. The catalog only contains `"zai-org/GLM-4.7-TEE"` (line 216) and `"zai-org/GLM-4.7-FP8"` (line 378). Any user who invokes `chutes-fast` will get a model-not-found error at runtime. Based on the other two aliases, the likely intended model is one of those two — `TEE` for the TEE-attested secure variant or `FP8` for the quantized variant. ```suggestion models["chutes-fast"] = { alias: "chutes/zai-org/GLM-4.7-TEE" }; ``` How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-03-06T13:05:54Z

+export async function setChutesApiKey(key: string, agentDir?: string) {
+  // Write to resolved agent dir so gateway finds credentials on startup.
+  upsertAuthProfile({
+    profileId: "chutes:default",
+    credential: {
+      type: "api_key",
+      provider: "chutes",
+      key,
+    },
+    agentDir: resolveAuthAgentDir(agentDir),
+  });
+}


Inconsistent signature vs other set*ApiKey helpers

Every other set*ApiKey function in this file accepts a SecretInput type (not plain string) and an optional ApiKeyStorageOptions, then delegates to buildApiKeyCredential. This new function accepts a bare string and constructs the credential inline, bypassing:

Encrypted/obfuscated storage modes supported by buildApiKeyCredential.

Any future ApiKeyStorageOptions features (e.g., key rotation hints) which will apply to all other providers but silently not Chutes.

It should follow the same shape as setVeniceApiKey and setSyntheticApiKey immediately above it in this file.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/commands/onboard-auth.credentials.ts Line: 332-343 Comment: **Inconsistent signature vs other `set*ApiKey` helpers** Every other `set*ApiKey` function in this file accepts a `SecretInput` type (not plain `string`) and an optional `ApiKeyStorageOptions`, then delegates to `buildApiKeyCredential`. This new function accepts a bare `string` and constructs the credential inline, bypassing: 1. Encrypted/obfuscated storage modes supported by `buildApiKeyCredential`. 2. Any future `ApiKeyStorageOptions` features (e.g., key rotation hints) which will apply to all other providers but silently not Chutes. It should follow the same shape as `setVeniceApiKey` and `setSyntheticApiKey` immediately above it in this file. How can I resolve this? If you propose a fix, please make it concise.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1f34bd639b

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-03-06T13:12:10Z

+export async function setChutesApiKey(key: string, agentDir?: string) {
+  // Write to resolved agent dir so gateway finds credentials on startup.
+  upsertAuthProfile({
+    profileId: "chutes:default",
+    credential: {


Preserve SecretRef storage for Chutes API credentials

setChutesApiKey stores the credential as a raw key string instead of using the shared buildApiKeyCredential path, so onboarding flows that pass a SecretRef (for secret-input-mode=ref) end up serializing an object into key rather than keyRef. That breaks the expected secret-ref behavior and can fail later when auth resolution treats key as a string (e.g., trimming/normalization paths). This makes Chutes onboarding uniquely unsafe/unstable compared with other API-key providers.

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-03-06T13:12:10Z

+      return null;
+    }
+    if (resolved.source !== "profile") {
+      await setChutesApiKey(resolved.key);


Honor ref-mode in non-interactive Chutes API-key onboarding

The non-interactive chutes-api-key branch writes resolved.key directly whenever the source is not profile, bypassing the maybeSetResolvedApiKey helper used by other providers. With --secret-input-mode ref, this stores the plaintext secret value instead of an env SecretRef, violating the caller’s explicit storage mode and leaking secrets into auth profiles.

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-03-06T13:12:10Z

+  // but init.sh uses 'chutes/' + m.id.
+
+  // Add aliases from init.sh
+  models["chutes-fast"] = { alias: "chutes/zai-org/GLM-4.7-Flash" };


Define Chutes model aliases in canonical direction

These alias entries are inverted for this config schema: the map key should be the real model ref and alias should be the shortcut. Here the shortcut is used as the key and the full model ref is stored as the alias, so alias resolution maps the wrong way (e.g., toward chutes/chutes-fast) and users cannot reliably select the intended canonical model via chutes-fast.

Useful? React with 👍 / 👎.

- Correct chutes-fast alias to point to a valid model (GLM-4.7-FP8) - Align setChutesApiKey signature with other providers (accept SecretInput) - Use maybeSetResolvedApiKey in non-interactive Chutes onboarding - Fix test mock data to match ChutesModelEntry API shape Made-with: Cursor

…t detections) - Fix Feishu media download/upload type errors by removing redundant timeout parameter (handled by client) - Add 'pragma: allowlist secret' to false-positive test tokens and translations Made-with: Cursor

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1b8192f110

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-03-06T20:29:45Z

+  // Write to resolved agent dir so gateway finds credentials on startup.
+  upsertAuthProfile({
+    profileId: "chutes:default",
+    credential: buildApiKeyCredential("chutes", key, undefined, options),


Add Chutes env-var mapping for ref-mode API key storage

setChutesApiKey now delegates to buildApiKeyCredential("chutes", ...), and that path calls resolveProviderDefaultEnvSecretRef when secret-input-mode=ref is used with a plaintext token; however PROVIDER_ENV_VARS has no chutes entry, so onboarding can throw Provider "chutes" does not have a default env var mapping... instead of saving credentials. This breaks chutes-api-key onboarding for ref-mode inputs (for example --auth-choice chutes-api-key --secret-input-mode ref with a direct token value) and should be fixed by wiring a default env var such as CHUTES_API_KEY.

Useful? React with 👍 / 👎.

…/chutesai/openclaw into feat/chutes-provider-integration

Replace complex state-mutation helper with direct applyChutesConfig call after OAuth success, matching the pattern used by the API key flow. This reliably sets the Chutes default model so the model picker shows a Chutes model as current instead of falling back to the previous anthropic default. Made-with: Cursor

The timeout parameter was removed from the source code in a previous commit because it was causing type errors with the SDK, but the tests were not updated. This brings the tests in sync with the source. Made-with: Cursor

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c265f21f8a

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-03-06T20:52:21Z

+  if (cachedModels && now - lastDiscoveryTime < CACHE_TTL) {
+    return cachedModels;


Key Chutes model cache by auth token

discoverChutesModels reuses a single global cache entry based only on TTL, before it inspects the incoming accessToken, so any subsequent discovery within 5 minutes returns the first fetched catalog regardless of which credential is being resolved. Since resolveImplicitProviders can run for different agent dirs/profiles in the same process, this can serve the wrong model set after switching Chutes accounts or credentials (for example, stale or account-mismatched model availability).

Useful? React with 👍 / 👎.

👎

Model discovery is the same for everyone, no matter the account or a credential

Conflict resolutions: - src/secrets/target-registry-pattern.ts: take upstream's named-variable style for sibling_ref check; preserve pragma allowlist comment - extensions/feishu/src/media.test.ts: keep upstream's expectMediaTimeoutClientConfigured() + add PR's imageCreateMock assertion for image_type verification - src/agents/models-config.providers.ts: adopt upstream's refactored provider-loader pattern (SIMPLE/PROFILE_IMPLICIT_PROVIDER_LOADERS); wire Chutes into both API-key (withApiKey) and OAuth profile (withProfilePresence) loader slots using buildChutesProvider from the new models-config.providers.discovery.ts boundary Supporting changes: - src/agents/models-config.providers.discovery.ts: add buildChutesProvider (dynamic model discovery via discoverChutesModels) - src/agents/model-auth-markers.ts: add CHUTES_OAUTH_MARKER and register it in isNonSecretApiKeyMarker Made-with: Cursor

openclaw-barnacle · 2026-03-09T19:21:08Z