OpenClaw's setup and onboarding commands now reject invalid options before they can write bad state. The fix landed in PR #111680, a P1 CLI change titled "fix(onboard): reject invalid setup options before writes."
The issue was not that setup failed loudly. It was more dangerous than that: some invalid values could look successful. The PR describes malformed Gateway ports, unknown flows, invalid remote URLs, unsupported daemon runtimes, unsupported node managers, and incompatible setup --baseline options that could be silently ignored, converted into defaults, or persisted before validation ran.
The New Boundary
Validation now happens at the canonical pre-dispatch boundary. That means OpenClaw checks setup inputs before config, credentials, or workspace state are mutated. Gateway ports use the existing strict parser, remote mode reuses the canonical WebSocket URL validator, and baseline mode checks only the Commander options that were explicitly supplied.
The PR also restores a documented setup path: openclaw setup --tui now routes into the same onboarding flow instead of failing as an unrecognized option.
The practical result is simple:
- Invalid Gateway ports fail before config is created.
- Unknown flows and runtime choices fail clearly.
- Remote URLs must pass the canonical WebSocket validation path.
- Baseline automation reports conflicting options instead of silently picking a different path.
- Valid non-interactive JSON onboarding still emits parseable JSON.
Why This Is Good Setup Design
Onboarding is a high-leverage surface. A failed setup is annoying, but a setup that appears to succeed while writing unusable state is worse. It can leave operators debugging later Gateway behavior, broken remote URLs, or automation config without realizing the bad value was accepted at the start.
Fail-fast validation is especially important for scripted installs and fleet-style setup. CI scripts, provisioning workflows, and remote bootstrap commands all need predictable exit codes. A nonzero exit status with untouched state is much easier to recover from than a successful-looking command that wrote defaults after receiving invalid input.
Evidence
The PR includes before-and-after examples from the old behavior. Invalid ports such as not-a-port and 70000 previously exited successfully and persisted the default port. Invalid flow and runtime choices could also write config. After the fix, the same invalid matrix exits with status 1 before creating config.
The focused proof includes 96 tests across onboarding and setup command registration, a source-mode black-box CLI matrix, docs listing, autoreview, a remote pnpm check:changed && pnpm build, and a clean git diff --check.
For anyone automating OpenClaw installs, this is a small interface change with a large reliability payoff: bad setup input now stops at the door.