#22662: fix: use OPENCLAW_GATEWAY_TOKEN env var in onboard QuickStart

The onboard wizard generates a random token for gateway auth, ignoring the OPENCLAW_GATEWAY_TOKEN environment variable injected by docker-setup.sh. This causes a permanent token mismatch: the gateway container has one token in the env var while openclaw.json holds a different one, breaking all CLI commands without --token. Fall back to process.env.OPENCLAW_GATEWAY_TOKEN when no existing config token is present, so docker-setup.sh and onboard stay in sync. ## Summary - **Problem**: `docker-setup.sh` generates a 64-char gateway token and injects it as `OPENCLAW_GATEWAY_TOKEN` env var, but the onboard QuickStart wizard ignores it and generates its own 48-char token into `openclaw.json`. This causes a permanent token mismatch — all CLI commands fail with `unauthorized: device token mismatch` without `--token`. - **Why it matters**: Every fresh Docker setup is broken out of the box. 100% reproducible on clean installs. - **What changed**: Fall back to `process.env.OPENCLAW_GATEWAY_TOKEN` when no existing config token is present in `src/wizard/onboarding.ts` (1 line). - **What did NOT change**: Existing config token priority is preserved. Non-Docker setups (no env var) still generate a random token as before. ## Change Type (select all) - [x] Bug fix ## Scope (select all touched areas) - [x] Auth / tokens - [x] UI / DX ## Linked Issue/PR - Closes #22638 - Related #22062 - Related #22616 ## User-visible / Behavior Changes When `OPENCLAW_GATEWAY_TOKEN` is set in the environment (e.g. via `docker-compose.yml`), the onboard QuickStart wizard now uses that token instead of generating a new one. This ensures `docker-setup.sh` and the gateway config stay in sync. ## Security Impact (required) - New permissions/capabilities? `No` - Secrets/tokens handling changed? `Yes` — the onboard wizard now reads an existing env var instead of always generating a new token. This does not introduce new token creation or storage; it reuses a token the user/script already injected. - New/changed network calls? `No` - Command/tool execution surface changed? `No` - Data access scope changed? `No` - Risk + mitigation: The env var is already trusted (injected by docker-setup.sh and docker-compose.yml). The fallback chain is: config file token > env var > random generation, so existing setups are unaffected. ## Repro + Verification ### Environment - OS: Ubuntu (Linux 6.17.0-1008-nvidia) - Runtime/container: Docker (node:22-bookworm) - Model/provider: Google Gemini - Relevant config: `gateway.auth.mode=token`, `gateway.bind=lan` ### Steps 1. Clean environment: `rm -rf ~/.openclaw .env` 2. Run `./docker-setup.sh`, complete QuickStart onboard 3. Run `docker exec <container> pnpm openclaw devices list` (no `--token`) ### Expected - CLI connects successfully without `--token` flag ### Actual (before fix) - `unauthorized: device token mismatch (rotate/reissue device token)` - Container env `OPENCLAW_GATEWAY_TOKEN` = 64-char token from docker-setup.sh - `openclaw.json` `gateway.auth.token` = different 48-char token from onboard ## Evidence - [x] Trace/log snippets ``` # Before fix: two different tokens $ docker exec <ctr> printenv OPENCLAW_GATEWAY_TOKEN ab42b703892fd83e25758ed9ac3fd834fb1689e7b891cd9c2a308f759ffdf6cc $ docker exec <ctr> grep token /home/node/.openclaw/openclaw.json "token": "49c6652a4147da3718640f3c2046414259e20ab7fcdc0b13" # After fix: tokens match ``` ## Human Verification (required) - Verified scenarios: Clean Docker install with `docker-setup.sh` → onboard QuickStart → CLI commands work without `--token` - Edge cases checked: Existing config with pre-set token (unchanged behavior), no env var set (falls back to `randomToken()` as before) - What I did **not** verify: Windows, macOS native installs (not affected — env var is Docker-specific) ## Compatibility / Migration - Backward compatible? `Yes` - Config/env changes? `No` - Migration needed? `No` ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: Revert the single line in `src/wizard/onboarding.ts` - Files/config to restore: `src/wizard/onboarding.ts` - Known bad symptoms reviewers should watch for: If `OPENCLAW_GATEWAY_TOKEN` is set to an invalid value, the gateway will reject connections (same as manually entering a wrong token during onboard) ## Risks and Mitigations - Risk: `OPENCLAW_GATEWAY_TOKEN` could be stale from a previous run - Mitigation: `docker-setup.sh` regenerates the token each run and writes it to `.env`; `docker compose` always reads the latest `.env` _This PR was AI-assisted (Cursor + Claude). The change was fully tested via Docker build + `pnpm tsgo` + `pnpm test` (8458/8461 passed; 2 pre-existing failures unrelated to this change)._ <!-- greptile_comment --> <h3>Greptile Summary</h3> Fixes Docker setup token mismatch by falling back to `OPENCLAW_GATEWAY_TOKEN` env var when no config token exists. Previously, the QuickStart onboard wizard always generated a new random token, ignoring the 64-char token injected by `docker-setup.sh`, causing CLI commands to fail with `unauthorized: device token mismatch`. The fix adds a simple nullish coalescing fallback to use the env var before generating a random token, maintaining backward compatibility with existing configs and non-Docker setups. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - Single-line fix with proper fallback chain (config > env var > random generation). The change preserves existing behavior for all non-Docker setups and only activates when `OPENCLAW_GATEWAY_TOKEN` is set in the environment. The env var is already trusted (injected by docker-setup.sh and docker-compose.yml). No syntax errors, no logic errors, and the fix directly addresses the reported token mismatch issue. - No files require special attention _{Last reviewed commit: b7ff67e} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->