refactor: move synthetic auth refs to manifests

This commit is contained in:
Peter Steinberger
2026-04-18 19:52:23 +01:00
parent ebfab7bf84
commit 796f272f7d
11 changed files with 116 additions and 66 deletions

View File

@@ -96,6 +96,7 @@ Those belong in your plugin code and `package.json`.
"modelPrefixes": ["router-"]
},
"cliBackends": ["openrouter-cli"],
"syntheticAuthRefs": ["openrouter-cli"],
"providerAuthEnvVars": {
"openrouter": ["OPENROUTER_API_KEY"]
},
@@ -153,6 +154,7 @@ Those belong in your plugin code and `package.json`.
| `providers` | No | `string[]` | Provider ids owned by this plugin. |
| `modelSupport` | No | `object` | Manifest-owned shorthand model-family metadata used to auto-load the plugin before runtime. |
| `cliBackends` | No | `string[]` | CLI inference backend ids owned by this plugin. Used for startup auto-activation from explicit config refs. |
| `syntheticAuthRefs` | No | `string[]` | Provider or CLI backend refs whose plugin-owned synthetic auth hook should be probed during cold model discovery before runtime loads. |
| `commandAliases` | No | `object[]` | Command names owned by this plugin that should produce plugin-aware config and CLI diagnostics before runtime loads. |
| `providerAuthEnvVars` | No | `Record<string, string[]>` | Cheap provider-auth env metadata that OpenClaw can inspect without loading plugin code. |
| `providerAuthAliases` | No | `Record<string, string>` | Provider ids that should reuse another provider id for auth lookup, for example a coding provider that shares the base provider API key and auth profiles. |
@@ -599,6 +601,10 @@ See [Configuration reference](/gateway/configuration) for the full `plugins.*` s
- `providerAuthAliases` lets provider variants reuse another provider's auth
env vars, auth profiles, config-backed auth, and API-key onboarding choice
without hardcoding that relationship in core.
- `syntheticAuthRefs` is the cheap metadata path for provider-owned synthetic
auth hooks that must be visible to cold model discovery before the runtime
registry exists. Only list refs whose runtime provider or CLI backend actually
implements `resolveSyntheticAuth`.
- `channelEnvVars` is the cheap metadata path for shell-env fallback, setup
prompts, and similar channel surfaces that should not boot plugin runtime
just to inspect env names.