Gateway
設定
OpenClaw は、任意の JSON5 設定を ~/.openclaw/openclaw.json から読み取ります。
アクティブな設定パスは通常ファイルである必要があります。シンボリックリンクされた openclaw.json
レイアウトは、OpenClaw が所有する書き込みではサポートされません。アトミックな書き込みにより、
シンボリックリンクを保持する代わりにパスが置き換えられる場合があります。設定を
既定の状態ディレクトリ外に置く場合は、OPENCLAW_CONFIG_PATH が実体ファイルを直接指すようにしてください。
ファイルが存在しない場合、OpenClaw は安全な既定値を使用します。設定を追加する一般的な理由:
- チャンネルを接続し、誰がボットにメッセージを送れるかを制御する
- モデル、ツール、サンドボックス化、または自動化(cron、フック)を設定する
- セッション、メディア、ネットワーク、または UI を調整する
利用可能なすべてのフィールドについては、完全なリファレンスを参照してください。
エージェントと自動化は、設定を編集する前に、正確なフィールド単位の
ドキュメントとして config.schema.lookup を使用してください。このページはタスク指向のガイダンスに使用し、
より広いフィールドマップと既定値については
設定リファレンスを使用してください。
最小設定
// ~/.openclaw/openclaw.json{ agents: { defaults: { workspace: "~/.openclaw/workspace" } }, channels: { whatsapp: { allowFrom: ["+15555550123"] } },}設定の編集
対話型ウィザード
openclaw onboard # full onboarding flowopenclaw configure # config wizardCLI(ワンライナー)
openclaw config get agents.defaults.workspaceopenclaw config set agents.defaults.heartbeat.every "2h"openclaw config unset plugins.entries.brave.config.webSearch.apiKeyControl UI
http://127.0.0.1:18789 を開き、Config タブを使用します。
Control UI は、ライブ設定スキーマからフォームをレンダリングします。利用可能な場合はフィールドの
title / description ドキュメントメタデータに加え、Plugin とチャンネルのスキーマも含み、
退避手段として Raw JSON エディタを提供します。ドリルダウン
UI やその他のツール向けに、Gateway は config.schema.lookup も公開しており、
パススコープのスキーマノード 1 つと直下の子サマリーを取得できます。
直接編集
~/.openclaw/openclaw.json を直接編集します。Gateway はファイルを監視し、変更を自動的に適用します(ホットリロードを参照)。
厳密な検証
openclaw config schema は、Control UI と検証で使用される正規の JSON Schema を出力します。
config.schema.lookup は、ドリルダウンツール向けに、パススコープのノード 1 つと
子サマリーを取得します。フィールドの title/description ドキュメントメタデータは、
ネストされたオブジェクト、ワイルドカード(*)、配列アイテム([])、および anyOf/
oneOf/allOf ブランチに引き継がれます。ランタイムの Plugin とチャンネルのスキーマは、
マニフェストレジストリが読み込まれるとマージされます。
検証に失敗した場合:
- Gateway は起動しません
- 診断コマンドのみ動作します(
openclaw doctor、openclaw logs、openclaw health、openclaw status) - 正確な問題を確認するには
openclaw doctorを実行します - 修復を適用するには
openclaw doctor --fix(または--yes)を実行します
Gateway は起動に成功するたびに信頼済みの最後の正常なコピーを保持しますが、
起動とホットリロードではそれを自動的に復元しません。openclaw.json が
検証に失敗した場合(Plugin ローカルの検証を含む)、Gateway の起動は失敗するか、
リロードがスキップされ、現在のランタイムは最後に受け入れられた設定を保持します。
プレフィックス付きまたは壊れた設定を修復するか、最後の正常なコピーを復元するには、
openclaw doctor --fix(または --yes)を実行します。候補に *** などの
秘匿済みシークレットプレースホルダーが含まれる場合、最後の正常なコピーへの昇格はスキップされます。
よくあるタスク
チャンネルをセットアップする(WhatsApp、Telegram、Discord など)
各チャンネルには channels.<provider> の下に独自の設定セクションがあります。セットアップ手順については、専用のチャンネルページを参照してください:
- WhatsApp -
channels.whatsapp - Telegram -
channels.telegram - Discord -
channels.discord - Feishu -
channels.feishu - Google Chat -
channels.googlechat - Microsoft Teams -
channels.msteams - Slack -
channels.slack - Signal -
channels.signal - iMessage -
channels.imessage - Mattermost -
channels.mattermost
すべてのチャンネルは同じ DM ポリシーパターンを共有します:
{ channels: { telegram: { enabled: true, botToken: "123:abc", dmPolicy: "pairing", // pairing | allowlist | open | disabled allowFrom: ["tg:123"], // only for allowlist/open }, },}モデルを選択して設定する
プライマリモデルと任意のフォールバックを設定します:
{ agents: { defaults: { model: { primary: "anthropic/claude-sonnet-4-6", fallbacks: ["openai/gpt-5.4"], }, models: { "anthropic/claude-sonnet-4-6": { alias: "Sonnet" }, "openai/gpt-5.4": { alias: "GPT" }, }, }, },}agents.defaults.modelsはモデルカタログを定義し、/modelの許可リストとして機能します。provider/*エントリは、動的モデル検出を引き続き使用しながら、/model、/models、モデルピッカーを選択されたプロバイダーに絞り込みます。- 既存のモデルを削除せずに許可リストエントリを追加するには、
openclaw config set agents.defaults.models '<json>' --strict-json --mergeを使用します。エントリを削除する通常の置換は、--replaceを渡さない限り拒否されます。 - モデル参照は
provider/model形式を使用します(例:anthropic/claude-opus-4-6)。 agents.defaults.imageMaxDimensionPxは、トランスクリプト/ツール画像の縮小を制御します(既定値1200)。値を低くすると、通常はスクリーンショットが多い実行で vision-token の使用量が減ります。- チャットでモデルを切り替える方法については Models CLI を、認証ローテーションとフォールバック動作については モデルフェイルオーバー を参照してください。
- カスタム/セルフホストのプロバイダーについては、リファレンスの カスタムプロバイダー を参照してください。
誰がボットにメッセージを送れるかを制御する
DM アクセスは dmPolicy を通じてチャンネルごとに制御されます:
"pairing"(既定): 不明な送信者は承認用の一回限りのペアリングコードを受け取る"allowlist":allowFrom(またはペアリング済み許可ストア)内の送信者のみ"open": すべての受信 DM を許可する(allowFrom: ["*"]が必要)"disabled": すべての DM を無視する
グループでは、groupPolicy + groupAllowFrom またはチャンネル固有の許可リストを使用します。
チャンネルごとの詳細については、完全なリファレンスを参照してください。
グループチャットのメンションゲートをセットアップする
グループメッセージは既定でメンションを要求します。エージェントごとにトリガーパターンを設定します。通常のグループ/チャンネル返信は自動的に投稿されます。エージェントが発言タイミングを判断すべき共有ルームでは、message-tool パスを明示的に有効にします:
{ messages: { visibleReplies: "automatic", // set "message_tool" to require message-tool sends everywhere groupChat: { visibleReplies: "message_tool", // opt-in; visible output requires message(action=send) unmentionedInbound: "room_event", // unmentioned always-on group chatter is quiet context }, }, agents: { list: [ { id: "main", groupChat: { mentionPatterns: ["@openclaw", "openclaw"], }, }, ], }, channels: { whatsapp: { groups: { "*": { requireMention: true } }, }, },}- メタデータメンション: ネイティブ @メンション(WhatsApp のタップしてメンション、Telegram @bot など)
- テキストパターン:
mentionPatterns内の安全な正規表現パターン - 表示される返信:
messages.visibleRepliesはグローバルに message-tool 送信を要求できます。messages.groupChat.visibleRepliesはグループ/チャンネルに対してそれを上書きします。 - 表示返信モード、チャンネルごとの上書き、セルフチャットモードについては、完全なリファレンスを参照してください。
エージェントごとに Skills を制限する
共有ベースラインには agents.defaults.skills を使用し、その後、特定の
エージェントを agents.list[].skills で上書きします:
{ agents: { defaults: { skills: ["github", "weather"], }, list: [ { id: "writer" }, // inherits github, weather { id: "docs", skills: ["docs-search"] }, // replaces defaults { id: "locked-down", skills: [] }, // no skills ], },}Gateway チャンネルのヘルス監視を調整する
古くなったように見えるチャンネルを Gateway がどの程度積極的に再起動するかを制御します:
{ gateway: { channelHealthCheckMinutes: 5, channelStaleEventThresholdMinutes: 30, channelMaxRestartsPerHour: 10, }, channels: { telegram: { healthMonitor: { enabled: false }, accounts: { alerts: { healthMonitor: { enabled: true }, }, }, }, },}- ヘルス監視による再起動をグローバルに無効化するには、
gateway.channelHealthCheckMinutes: 0を設定します。 channelStaleEventThresholdMinutesはチェック間隔以上にする必要があります。- グローバル監視を無効にせず、1 つのチャンネルまたはアカウントの自動再起動を無効化するには、
channels.<provider>.healthMonitor.enabledまたはchannels.<provider>.accounts.<id>.healthMonitor.enabledを使用します。 - 運用時のデバッグについては ヘルスチェック を、すべてのフィールドについては 完全なリファレンス を参照してください。
Gateway WebSocket ハンドシェイクのタイムアウトを調整する
負荷が高いホストや低性能ホストで、ローカルクライアントが認証前の WebSocket ハンドシェイクを完了する時間を 長くします:
{ gateway: { handshakeTimeoutMs: 30000, },}- 既定値は
15000ミリ秒です。 OPENCLAW_HANDSHAKE_TIMEOUT_MSは、単発のサービスまたはシェルの上書きとして引き続き優先されます。- まず起動時やイベントループの停止を修正することを優先してください。このノブは、正常だがウォームアップ中に遅いホスト向けです。
セッションとリセットを設定する
セッションは会話の継続性と分離を制御します:
{ session: { dmScope: "per-channel-peer", // recommended for multi-user threadBindings: { enabled: true, idleHours: 24, maxAgeHours: 0, }, reset: { mode: "daily", atHour: 4, idleMinutes: 120, }, },}サンドボックス化を有効にする
エージェントセッションを分離されたサンドボックスランタイムで実行します。
{ agents: { defaults: { sandbox: { mode: "non-main", // off | non-main | all scope: "agent", // session | agent | shared }, }, },}まずイメージをビルドします。ソースチェックアウトからは scripts/sandbox-setup.sh を実行し、npm インストールからは サンドボックス化 § イメージとセットアップ のインライン docker build コマンドを参照してください。
公式 iOS ビルド向けのリレー経由プッシュを有効にする
公開 App Store ビルド向けのリレー経由プッシュは、ホストされた OpenClaw リレー https://ios-push-relay.openclaw.ai を使用します。
カスタムリレーデプロイには、リレー URL が Gateway のリレー URL と一致する、意図的に分離された iOS ビルド/デプロイ経路が必要です。カスタムリレービルドを使用している場合は、Gateway 設定でこれを指定します。
{ gateway: { push: { apns: { relay: { baseUrl: "https://relay.example.com", // Optional. Default: 10000 timeoutMs: 10000, }, }, }, },}CLI での同等操作:
openclaw config set gateway.push.apns.relay.baseUrl https://relay.example.comこれが行うこと:
- Gateway が
push.test、ウェイク促進、再接続ウェイクを外部リレー経由で送信できるようにします。 - ペアリング済み iOS アプリによって転送される、登録スコープの送信許可を使用します。Gateway にデプロイ全体のリレートークンは不要です。
- 各リレー経由登録を、iOS アプリがペアリングした Gateway ID に紐づけるため、別の Gateway が保存済み登録を再利用することはできません。
- ローカル/手動 iOS ビルドは直接 APNs のままにします。リレー経由送信は、リレーを通じて登録された公式配布ビルドにのみ適用されます。
- iOS ビルドに組み込まれたリレーベース URL と一致している必要があり、登録トラフィックと送信トラフィックが同じリレーデプロイに到達します。
エンドツーエンドフロー:
- 公式 iOS アプリをインストールします。
- 任意: 意図的に分離されたカスタムリレービルドを使用する場合にのみ、Gateway で
gateway.push.apns.relay.baseUrlを設定します。 - iOS アプリを Gateway とペアリングし、node セッションとオペレーターセッションの両方を接続させます。
- iOS アプリは Gateway ID を取得し、App Attest とアプリレシートを使ってリレーに登録してから、リレー経由の
push.apns.registerペイロードをペアリング済み Gateway に公開します。 - Gateway はリレーハンドルと送信許可を保存し、それらを
push.test、ウェイク促進、再接続ウェイクに使用します。
運用上の注意:
- iOS アプリを別の Gateway に切り替える場合は、その Gateway に紐づく新しいリレー登録をアプリが公開できるよう、アプリを再接続してください。
- 別のリレーデプロイを指す新しい iOS ビルドを出荷する場合、アプリは古いリレーオリジンを再利用せず、キャッシュ済みリレー登録を更新します。
互換性に関する注意:
OPENCLAW_APNS_RELAY_BASE_URLとOPENCLAW_APNS_RELAY_TIMEOUT_MSは、一時的な環境変数オーバーライドとして引き続き機能します。- カスタム Gateway リレー URL は、iOS ビルドに組み込まれたリレーベース URL と一致している必要があります。公開 App Store リリースレーンは、カスタム iOS リレー URL オーバーライドを拒否します。
OPENCLAW_APNS_RELAY_ALLOW_HTTP=trueは local loopback 専用の開発用エスケープハッチのままです。HTTP リレー URL を設定に永続化しないでください。
エンドツーエンドフローについては iOS アプリ、リレーのセキュリティモデルについては 認証と信頼フロー を参照してください。
Heartbeat(定期チェックイン)をセットアップする
{ agents: { defaults: { heartbeat: { every: "30m", target: "last", }, }, },}every: 期間文字列(30m、2h)。無効にするには0mを設定します。target:last|none|<channel-id>(例:discord、matrix、telegram、またはwhatsapp)directPolicy: DM 形式の Heartbeat ターゲットに対してallow(デフォルト)またはblock- 完全なガイドについては Heartbeat を参照してください。
Cron ジョブを設定する
{ cron: { enabled: true, maxConcurrentRuns: 8, // default; cron dispatch + isolated cron agent-turn execution sessionRetention: "24h", runLog: { maxBytes: "2mb", keepLines: 2000, }, },}sessionRetention: 完了した分離実行セッションをsessions.jsonから削除します(デフォルトは24h。無効にするにはfalseを設定)。runLog: ジョブごとに保持される Cron 実行履歴行を削除します。maxBytesは、古いファイルベースの実行ログ向けに引き続き受け入れられます。- 機能概要と CLI 例については Cron ジョブ を参照してください。
Webhook(フック)をセットアップする
Gateway で HTTP Webhook エンドポイントを有効にします。
{ hooks: { enabled: true, token: "shared-secret", path: "/hooks", defaultSessionKey: "hook:ingress", allowRequestSessionKey: false, allowedSessionKeyPrefixes: ["hook:"], mappings: [ { match: { path: "gmail" }, action: "agent", agentId: "main", deliver: true, }, ], },}セキュリティ上の注意:
- すべてのフック/Webhook ペイロード内容を信頼できない入力として扱ってください。
- 専用の
hooks.tokenを使用してください。有効な Gateway 認証シークレット(gateway.auth.token/OPENCLAW_GATEWAY_TOKENまたはgateway.auth.password/OPENCLAW_GATEWAY_PASSWORD)を再利用しないでください。 - フック認証はヘッダーのみです(
Authorization: Bearer ...またはx-openclaw-token)。クエリ文字列トークンは拒否されます。 hooks.pathを/にすることはできません。Webhook の受信は/hooksのような専用サブパスに保持してください。- 厳密にスコープされたデバッグを行う場合を除き、安全でないコンテンツのバイパスフラグ(
hooks.gmail.allowUnsafeExternalContent、hooks.mappings[].allowUnsafeExternalContent)は無効のままにしてください。 hooks.allowRequestSessionKeyを有効にする場合は、呼び出し元が選択するセッションキーを制限するためにhooks.allowedSessionKeyPrefixesも設定してください。- フック駆動エージェントでは、強力な最新モデル階層と厳格なツールポリシーを優先してください(例: 可能な場合はメッセージングのみとサンドボックス化)。
すべてのマッピングオプションと Gmail 連携については 完全なリファレンス を参照してください。
マルチエージェントルーティングを設定する
個別のワークスペースとセッションを持つ複数の分離エージェントを実行します。
{ agents: { list: [ { id: "home", default: true, workspace: "~/.openclaw/workspace-home" }, { id: "work", workspace: "~/.openclaw/workspace-work" }, ], }, bindings: [ { agentId: "home", match: { channel: "whatsapp", accountId: "personal" } }, { agentId: "work", match: { channel: "whatsapp", accountId: "biz" } }, ],}バインドルールとエージェントごとのアクセスプロファイルについては マルチエージェント と 完全なリファレンス を参照してください。
設定を複数ファイルに分割する($include)
大きな設定を整理するには $include を使用します。
// ~/.openclaw/openclaw.json{ gateway: { port: 18789 }, agents: { $include: "./agents.json5" }, broadcast: { $include: ["./clients/a.json5", "./clients/b.json5"], },}- 単一ファイル: 含む側のオブジェクトを置き換えます
- ファイル配列: 順番にディープマージされます(後のものが優先)
- 兄弟キー: include 後にマージされます(include された値を上書き)
- ネストされた include: 最大 10 階層までサポートされます
- 相対パス: include しているファイルを基準に解決されます
- パス形式: include パスには null バイトを含めてはならず、解決前後の両方で 4096 文字未満でなければなりません
- OpenClaw が所有する書き込み: 書き込みが、
plugins: { $include: "./plugins.json5" }のような単一ファイル include に支えられた 1 つのトップレベルセクションのみを変更する場合、OpenClaw はその include されたファイルを更新し、openclaw.jsonはそのままにします - サポートされない書き込みスルー: ルート include、include 配列、兄弟上書きを伴う include は、設定をフラット化する代わりに、OpenClaw が所有する書き込みに対して fail closed します
- 閉じ込め:
$includeパスはopenclaw.jsonを保持するディレクトリ配下に解決される必要があります。マシン間またはユーザー間でツリーを共有するには、include が参照できる追加ディレクトリのパスリスト(POSIX では:、Windows では;)をOPENCLAW_INCLUDE_ROOTSに設定します。シンボリックリンクは解決されて再チェックされるため、字句上は設定ディレクトリ内にあるパスでも、実際のターゲットが許可されたすべてのルートから外れている場合は拒否されます。 - エラー処理: ファイル欠落、パースエラー、循環 include、無効なパス形式、過大な長さに対して明確なエラーを出します
設定のホットリロード
Gateway は ~/.openclaw/openclaw.json を監視し、変更を自動的に適用します。ほとんどの設定では手動再起動は不要です。
直接のファイル編集は、検証に通るまで信頼されません。ウォッチャーはエディターの一時書き込み/リネームの揺れが落ち着くのを待ち、最終ファイルを読み取り、無効な外部編集を openclaw.json を書き換えずに拒否します。OpenClaw が所有する設定書き込みは、書き込み前に同じスキーマゲートを使用します。gateway.mode の削除やファイルサイズを半分未満に縮小するような破壊的な上書きは拒否され、確認用に .rejected.* として保存されます。
config reload skipped (invalid config) が表示される場合、または起動時に Invalid config が報告される場合は、設定を確認し、openclaw config validate を実行してから、修復のために openclaw doctor --fix を実行してください。チェックリストについては Gateway トラブルシューティング を参照してください。
リロードモード
| モード | 動作 |
|---|---|
hybrid(デフォルト) |
安全な変更を即座にホット適用します。重要な変更では自動的に再起動します。 |
hot |
安全な変更のみをホット適用します。再起動が必要な場合は警告をログに出します。対応は手動です。 |
restart |
安全かどうかに関係なく、設定変更時に Gateway を再起動します。 |
off |
ファイル監視を無効にします。変更は次回の手動再起動時に有効になります。 |
{ gateway: { reload: { mode: "hybrid", debounceMs: 300 }, },}ホット適用されるものと再起動が必要なもの
ほとんどのフィールドはダウンタイムなしでホット適用されます。hybrid モードでは、再起動が必要な変更は自動的に処理されます。
| カテゴリ | フィールド | 再起動が必要? |
|---|---|---|
| チャンネル | channels.*, web (WhatsApp) - すべての組み込みチャンネルと Plugin チャンネル |
いいえ |
| エージェントとモデル | agent, agents, models, routing |
いいえ |
| 自動化 | hooks, cron, agent.heartbeat |
いいえ |
| セッションとメッセージ | session, messages |
いいえ |
| ツールとメディア | tools, browser, skills, mcp, audio, talk |
いいえ |
| UI とその他 | ui, logging, identity, bindings |
いいえ |
| Gateway サーバー | gateway.* (port, bind, auth, tailscale, TLS, HTTP) |
はい |
| インフラストラクチャ | discovery, plugins |
はい |
リロード計画
$include を通じて参照されるソースファイルを編集すると、OpenClaw は
フラット化されたメモリ内ビューではなく、ソースで記述されたレイアウトから
リロードを計画します。これにより、plugins: { $include: "./plugins.json5" } のように
単一のトップレベルセクションが独自のインクルードファイルにある場合でも、
ホットリロードの判断(ホット適用か再起動か)が予測しやすくなります。
ソースレイアウトが曖昧な場合、リロード計画は安全側に倒れて失敗します。
Config RPC(プログラムによる更新)
Gateway API 経由で設定を書き込むツールでは、次のフローを推奨します。
config.schema.lookupで 1 つのサブツリーを調べる(浅いスキーマノード + 子の 要約)config.getで現在のスナップショットとhashを取得するconfig.patchで部分更新する(JSON マージパッチ: オブジェクトはマージされ、nullは削除され、配列は、エントリが削除される場合にreplacePathsで明示的に確認されたときのみ置換される)- 設定全体を置き換える意図がある場合のみ
config.applyを使う - 明示的な自己更新と再起動には
update.runを使う。再起動後のセッションで 1 回のフォローアップターンを実行する必要がある場合はcontinuationMessageを含める update.statusで最新の更新再起動センチネルを調べ、再起動後に実行中のバージョンを確認する
エージェントは、正確なフィールドレベルのドキュメントと制約の最初の参照先として
config.schema.lookup を扱うべきです。より広い設定マップ、デフォルト、または専用の
サブシステムリファレンスへのリンクが必要な場合は、設定リファレンス
を使ってください。
部分パッチの例:
openclaw gateway call config.get --params '{}' # capture payload.hashopenclaw gateway call config.patch --params '{ "raw": "{ channels: { telegram: { groups: { \"*\": { requireMention: false } } } } }", "baseHash": "<hash>"}'config.apply と config.patch はどちらも raw, baseHash, sessionKey,
note, restartDelayMs を受け取ります。設定がすでに存在する場合、baseHash は
両方のメソッドで必須です。
config.patch は、配列置換が意図的である設定パスの配列 replacePaths も受け取ります。
パッチが既存の配列をより少ないエントリで置換または削除しようとする場合、その正確なパスが
replacePaths に含まれていない限り、Gateway は書き込みを拒否します。配列エントリ配下の
ネストされた配列には、agents.list[].skills のように [] を使います。これにより、
切り詰められた config.get スナップショットがルーティングや許可リストの配列を
暗黙に上書きすることを防ぎます。完全な設定を置き換える意図がある場合は config.apply
を使ってください。
環境変数
OpenClaw は親プロセスに加えて、次から環境変数を読み取ります。
- 現在の作業ディレクトリの
.env(存在する場合) ~/.openclaw/.env(グローバルフォールバック)
どちらのファイルも既存の環境変数を上書きしません。設定内でインライン環境変数を設定することもできます。
{ env: { OPENROUTER_API_KEY: "sk-or-...", vars: { GROQ_API_KEY: "gsk-..." }, },}シェル環境のインポート(任意)
有効化され、期待されるキーが設定されていない場合、OpenClaw はログインシェルを実行し、不足しているキーのみをインポートします。
{env: { shellEnv: { enabled: true, timeoutMs: 15000 },},}環境変数での同等指定: OPENCLAW_LOAD_SHELL_ENV=1
設定値内の環境変数置換
任意の設定文字列値で ${VAR_NAME} を使って環境変数を参照します。
{gateway: { auth: { token: "${OPENCLAW_GATEWAY_TOKEN}" } },models: { providers: { custom: { apiKey: "${CUSTOM_API_KEY}" } } },}ルール:
- 一致するのは大文字の名前のみ:
[A-Z_][A-Z0-9_]* - 未設定または空の変数は読み込み時にエラーを投げる
- リテラル出力には
$${VAR}でエスケープする $includeファイル内でも動作する- インライン置換:
"${BASE}/v1"→"https://api.example.com/v1"
シークレット参照(env, file, exec)
SecretRef オブジェクトをサポートするフィールドでは、次を使用できます。
{models: { providers: { openai: { apiKey: { source: "env", provider: "default", id: "OPENAI_API_KEY" } }, },},skills: { entries: { "image-lab": { apiKey: { source: "file", provider: "filemain", id: "/skills/entries/image-lab/apiKey", }, }, },},channels: { googlechat: { serviceAccountRef: { source: "exec", provider: "vault", id: "channels/googlechat/serviceAccount", }, },},}SecretRef の詳細(env/file/exec 用の secrets.providers を含む)は シークレット管理 にあります。
サポートされる認証情報パスは SecretRef 認証情報サーフェス に一覧されています。
完全な優先順位とソースについては、環境 を参照してください。
完全なリファレンス
フィールドごとの完全なリファレンスについては、設定リファレンス を参照してください。