openclaw - ✅(Solved) Fix [Bug]: onboard wizard stores env var reference as apiKey; breaks channels that don't resolve it [2 pull requests, 2 comments, 3 participants]

Q: Expected behavior

The onboard wizard should resolve `${MIMO_API_KEY}` to its actual value before writing to config. Alternatively, all channel implementations should consistently resolve env var references. Either way, the same config should work identically across webchat and Feishu.

yuyzhen · 2026-03-21T09:48:42Z

[openclaw] The onboard wizard stores "${MIMO API KEY}" env var reference in config instead of the resolved value. Webchat resolves it correctly at runtime but… The onboard wizard stores "${MIMO_API_KEY}" (env var reference) in config instead of the resolved value. Webchat resolves it correctly at runtime but Feishu channel passes the literal string to the model API, causing 401 errors. # PR #51582: fix(extensions): align MIMO_API_KEY for Xiaomi extensions across plugin, usage, tests and docs - Repository: openclaw/openclaw - Author: jepson-liu - State: closed | merged: False - Link: https://github.com/openclaw/openclaw/pull/51582 ## Description (problem / solution / changelog) ## Summary - Problem: Xiaomi auth paths accepted `XIAOMI_API_KEY` only in some places, while real-world setup commonly uses `MIMO_API_KEY` (including Xiaomi’s official OpenAI SDK example). - Why it matters: users could pass onboarding and environment checks but still hit inconsistent auth behavior across runtime and channel paths. - What changed: aligned Xiaomi auth env resolution to support `MIMO_API_KEY` alongside `XIAOMI_API_KEY` across plugin metadata, bundled env-var generation, usage auth fallback, e2e harness env snapshot, targeted tests, and docs. - What did NOT change (scope boundary): no provider API contract changes, no channel routing logic changes, and no broad secrets-resolution refactor. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor required for the fix - [x] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [x] Auth / tokens - [ ] Memory / storage - [x] Integrations - [x] API / contracts - [x] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Fixes #51533 ## User-visible / Behavior Changes - Xiaomi provider now recognizes both `MIMO_API_KEY` and `XIAOMI_API_KEY`. - Xiaomi onboarding/help text and provider docs now reflect both env vars. - Usage auth fallback for Xiaomi now prefers `MIMO_API_KEY` when both are present. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`Yes`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: - Risk is limited to env-var selection precedence for Xiaomi API key lookup. - Mitigation: deterministic precedence (`MIMO_API_KEY` then `XIAOMI_API_KEY`) with targeted tests for normalization and precedence. ## Repro + Verification ### Environment - OS: Linux - Runtime/container: Node + pnpm - Model/provider: Xiaomi (`xiaomi/*`) - Integration/channel (if any): provider auth / usage auth paths - Relevant config (redacted): `models.providers.xiaomi.apiKey: "${MIMO_API_KEY}"` ### Steps 1. Set `MIMO_API_KEY` in env. 2. Configure Xiaomi provider / run onboarding auth choice. 3. Trigger Xiaomi auth resolution and usage auth fallback paths. ### Expected - Xiaomi auth resolves successfully from `MIMO_API_KEY` (or `XIAOMI_API_KEY`). - No literal `${MIMO_API_KEY}` leakage into runtime auth token usage paths for Xiaomi lookups covered by this patch. ### Actual - Verified expected behavior after patch. ## Evidence - [x] Failing-path coverage added/updated and passing after - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) - Verified scenarios: - Bundled provider auth env var generation includes Xiaomi dual-env mapping. - Xiaomi usage auth fallback resolves from `MIMO_API_KEY`. - Xiaomi auth-choice targeted test path remains green. - Edge cases checked: - Embedded CR/LF normalization for `MIMO_API_KEY`. - Precedence when both `MIMO_API_KEY` and `XIAOMI_API_KEY` are set. - What you did **not** verify: - Full end-to-end live channel roundtrip with real Xiaomi credentials in this PR run. ## Review Conversations - [x] I replied to or resolved every bot review conversation I addressed in this PR. - [x] I left unresolved only the conversations that still need reviewer or maintainer judgment. ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`, additive env alias support) - Migration needed? (`No`) - If yes, exact upgrade steps: - N/A ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: - Revert this PR commit(s). - Files/config to restore: - `extensions/xiaomi/openclaw.plugin.json` - `extensions/xiaomi/index.ts` - `src/plugins/bundled-provider-auth-env-vars.generated.ts` - `src/infra/provider-usage.auth.ts` - Known bad symptoms reviewers should watch for: - Xiaomi auth unexpectedly preferring a different env key than intended. ## Risks and Mitigations - Risk: Confusion around which env var is shown in prompts/help. - Mitigation: docs and plugin metadata updated to explicitly mention both names. - Risk: Regression in usage-auth env precedence. - Mitigation: targeted normalization/precedence tests added an

openclaw2026-03-21 09:48:42

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#51533•Fetched 2026-04-08 01:09:55

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

commented ×2cross-referenced ×2referenced ×2

The onboard wizard stores "${MIMO_API_KEY}" (env var reference) in config instead of the resolved value. Webchat resolves it correctly at runtime but Feishu channel passes the literal string to the model API, causing 401 errors.

Root Cause

Root cause likely in the gateway config resolution layer: env var expansion works for webchat code path but not for the Feishu channel provider path.

Code Example

# Config grep:
$ grep apiKey ~/.openclaw/openclaw.json
  "apiKey": "${MIMO_API_KEY}",

# Gateway process env:
$ cat /proc/3296/environ | tr "\0" "\n" | grep MIMO_API_KEY
MIMO_API_KEY=oc_ct02k...

# Direct API test with resolved key → 200 OK
# Direct API test with literal "${MIMO_API_KEY}" → 401

# Feishu bot reply in chat:
"Sorry, something went wrong. HTTP 401: Invalid API Key"

# Gateway log shows Feishu channel connected successfully:
feishu[default]: WebSocket client started
feishu[default]: received message from ou_xxx (p2p)

RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

Steps to reproduce

Set MIMO_API_KEY as an environment variable on the host.
Run openclaw onboard — the wizard detects the env var and stores "apiKey": "${MIMO_API_KEY}" in ~/.openclaw/openclaw.json.
Configure a Feishu channel via openclaw channels add with App ID and App Secret.
Restart gateway, pair the Feishu bot user.
Send a message via Feishu bot → bot replies: HTTP 401: Invalid API Key.
Send a message via webchat → works fine (agent responds normally).

Expected behavior

The onboard wizard should resolve ${MIMO_API_KEY} to its actual value before writing to config. Alternatively, all channel implementations should consistently resolve env var references. Either way, the same config should work identically across webchat and Feishu.

Actual behavior

Webchat resolves ${MIMO_API_KEY} to the actual API key and works. Feishu channel passes the literal string ${MIMO_API_KEY} to the https://api.xiaomimimo.com/v1/chat/completions endpoint, which returns 401: Invalid API Key. Verified by grepping config: "apiKey": "${MIMO_API_KEY}", and confirmed the gateway process does have the real key in its environment (/proc/PID/environ).

OpenClaw version

2026.3.12

Operating system

Linux 6.8.0-100-generic (Ubuntu, x64)

Install method

npm global

Model

xiaomi/mimo-v2-pro

Provider / routing chain

openclaw -> api.xiaomimimo.com/v1

Additional provider/model setup details

Config: models.providers.xiaomi.baseUrl = "https://api.xiaomimimo.com/v1" apiKey stored as ${MIMO_API_KEY} env var reference in config. Gateway process has the resolved key in /proc/PID/environ.

Logs, screenshots, and evidence

# Config grep:
$ grep apiKey ~/.openclaw/openclaw.json
  "apiKey": "${MIMO_API_KEY}",

# Gateway process env:
$ cat /proc/3296/environ | tr "\0" "\n" | grep MIMO_API_KEY
MIMO_API_KEY=oc_ct02k...

# Direct API test with resolved key → 200 OK
# Direct API test with literal "${MIMO_API_KEY}" → 401

# Feishu bot reply in chat:
"Sorry, something went wrong. HTTP 401: Invalid API Key"

# Gateway log shows Feishu channel connected successfully:
feishu[default]: WebSocket client started
feishu[default]: received message from ou_xxx (p2p)

Impact and severity

Affected: All users adding Feishu channel when env var references exist in config. Severity: Medium (Feishu channel completely non-functional; workaround requires manual config edit). Frequency: Always reproducible when env var ref is used. Consequence: New channel setup fails silently — bot receives messages but cannot respond.

Additional information

Workaround: manually replace ${MIMO_API_KEY} with the actual key value in ~/.openclaw/openclaw.json and restart the gateway.

Root cause likely in the gateway config resolution layer: env var expansion works for webchat code path but not for the Feishu channel provider path.

extent analysis

Fix Plan

To resolve the issue, we need to ensure that the MIMO_API_KEY environment variable is properly expanded in the gateway config resolution layer for the Feishu channel provider path.

Here are the steps to fix the issue:

Modify the onboard wizard to resolve the MIMO_API_KEY environment variable before storing it in the config.
Alternatively, update the Feishu channel provider to expand environment variable references in the config.

Example code snippet to resolve the environment variable in the onboard wizard:

const apiKey = process.env.MIMO_API_KEY;
// Store the resolved apiKey in the config
config.apiKey = apiKey;

Example code snippet to expand environment variable references in the Feishu channel provider:

const config = // load config
const apiKey = config.apiKey;
if (apiKey.startsWith('${') && apiKey.endsWith('}')) {
  const varName = apiKey.substring(2, apiKey.length - 1);
  config.apiKey = process.env[varName];
}

Verification

To verify that the fix worked:

Run the onboard wizard and configure the Feishu channel.
Restart the gateway and pair the Feishu bot user.
Send a message via the Feishu bot and verify that the bot responds correctly.
Check the gateway logs to ensure that the MIMO_API_KEY environment variable is properly expanded.

Extra Tips

Make sure to handle cases where the environment variable is not set.
Consider adding a check to ensure that the MIMO_API_KEY environment variable is set before attempting to use it.
Use a consistent approach to expanding environment variable references throughout the codebase.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

#api #ssr #installation #tensor shape #model save/load #optimization #mixed precision #environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: onboard wizard stores env var reference as apiKey; breaks channels that don't resolve it [2 pull requests, 2 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #51582: fix(extensions): align MIMO_API_KEY for Xiaomi extensions across plugin, usage, tests and docs

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

PR #55144: fix(extensions): align MIMO_API_KEY for Xiaomi extensions across plug…

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

Code Example

Bug type

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

Fix Plan

Verification

Extra Tips

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING