fix: default gateway.mode to 'local' when unset (#54801)#60085
fix: default gateway.mode to 'local' when unset (#54801)#60085BradGroux merged 1 commit intoopenclaw:mainfrom
Conversation
After v2026.3.24 introduced a gateway.mode guard, startup fails on Windows (and other platforms) when the config file exists but doesn't contain an explicit gateway.mode value. This happens after 'openclaw onboard' writes a minimal config without gateway settings. Default to 'local' when the mode is unset, restoring pre-3.24 behavior where the gateway started without requiring an explicit mode. Fixes openclaw#54801
Greptile SummaryFixes a Windows startup regression introduced in v2026.3.24 by defaulting Confidence Score: 5/5Safe to merge — minimal, targeted fix with no functional regressions. Single-line logic change with a clear root cause and accurate fix. The only finding is a P2 dead-code nit ( No files require special attention.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 28bdeb6552
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // regressed startup on Windows (and other platforms) when the config file | ||
| // exists but doesn't contain gateway.mode — e.g. after `openclaw onboard` | ||
| // writes a minimal config. (#54801) | ||
| const mode = effectiveCfg.gateway?.mode ?? "local"; |
There was a problem hiding this comment.
Keep missing-config startup blocked by default
In runGatewayCommand, defaulting mode with ?? "local" makes the guard treat an entirely missing config as configured local mode (loadConfig() returns {} when no file exists). That means openclaw gateway run now bypasses the --allow-unconfigured gate on fresh installs, and the !configExists error path is no longer reachable in that case. This changes the CLI contract (“Allow gateway start without gateway.mode=local in config”) and removes the intended explicit opt-in for unconfigured environments.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Pull request overview
Adjusts the openclaw gateway run startup guard to avoid failing when the config exists but does not explicitly set gateway.mode, restoring the expected default behavior after a regression introduced in v2026.3.24.
Changes:
- Default
gateway.modeto"local"when it is unset in the effective config used bygateway run. - Add an inline comment explaining the regression scenario and rationale (issue #54801).
- Minor import reordering in
run.ts.
| // Default to "local" when gateway.mode is unset. Prior to v2026.3.24 the | ||
| // gateway started without an explicit mode; the guard added in 3.24 | ||
| // regressed startup on Windows (and other platforms) when the config file | ||
| // exists but doesn't contain gateway.mode — e.g. after `openclaw onboard` | ||
| // writes a minimal config. (#54801) | ||
| const mode = effectiveCfg.gateway?.mode ?? "local"; | ||
| if (!opts.allowUnconfigured && mode !== "local") { |
There was a problem hiding this comment.
mode is now defaulted to "local" unconditionally when gateway.mode is unset. That also changes behavior for the missing config file case: loadConfig() returns {} when the config path doesn’t exist, so mode becomes "local" and the !configExists error/exit path is bypassed. This effectively makes --allow-unconfigured meaningless for the no-config scenario and allows gateway run to proceed without any config.
Consider keeping the original fail-closed behavior when configExists is false (e.g., compute rawMode = effectiveCfg.gateway?.mode and only default to "local" when configExists is true, or incorporate configExists into the guard).
| // Default to "local" when gateway.mode is unset. Prior to v2026.3.24 the | |
| // gateway started without an explicit mode; the guard added in 3.24 | |
| // regressed startup on Windows (and other platforms) when the config file | |
| // exists but doesn't contain gateway.mode — e.g. after `openclaw onboard` | |
| // writes a minimal config. (#54801) | |
| const mode = effectiveCfg.gateway?.mode ?? "local"; | |
| if (!opts.allowUnconfigured && mode !== "local") { | |
| // Default to "local" when gateway.mode is unset, but only if a config file | |
| // actually exists. Prior to v2026.3.24 the gateway started without an | |
| // explicit mode; the guard added in 3.24 regressed startup on Windows (and | |
| // other platforms) when the config file exists but doesn't contain | |
| // gateway.mode — e.g. after `openclaw onboard` writes a minimal config. | |
| // Keep the original fail-closed behavior when the config file is missing. | |
| const rawMode = effectiveCfg.gateway?.mode; | |
| const mode = rawMode ?? (configExists ? "local" : undefined); | |
| if (!opts.allowUnconfigured && (!configExists || mode !== "local")) { |
| // Default to "local" when gateway.mode is unset. Prior to v2026.3.24 the | ||
| // gateway started without an explicit mode; the guard added in 3.24 | ||
| // regressed startup on Windows (and other platforms) when the config file | ||
| // exists but doesn't contain gateway.mode — e.g. after `openclaw onboard` | ||
| // writes a minimal config. (#54801) | ||
| const mode = effectiveCfg.gateway?.mode ?? "local"; | ||
| if (!opts.allowUnconfigured && mode !== "local") { |
There was a problem hiding this comment.
This change alters the semantics of the startup guard when gateway.mode is absent in the observed config snapshot. There is an existing unit test (src/cli/gateway-cli/run.option-collisions.test.ts, “blocks startup when the observed snapshot loses gateway.mode…”) that currently asserts gateway run exits with current: unset when the snapshot omits gateway.mode. With the new default-to-local behavior, that test (and potentially related expectations) will need to be updated/removed, and it would be good to add/adjust coverage for the intended regression case (config exists, no gateway section/mode → gateway starts).
After v2026.3.24 introduced a gateway.mode guard, startup fails on Windows (and other platforms) when the config file exists but doesn't contain an explicit gateway.mode value. This happens after 'openclaw onboard' writes a minimal config without gateway settings. Default to 'local' when the mode is unset, restoring pre-3.24 behavior where the gateway started without requiring an explicit mode. Fixes #54801 Co-authored-by: Brad Groux <[email protected]>
…nclaw#60085) After v2026.3.24 introduced a gateway.mode guard, startup fails on Windows (and other platforms) when the config file exists but doesn't contain an explicit gateway.mode value. This happens after 'openclaw onboard' writes a minimal config without gateway settings. Default to 'local' when the mode is unset, restoring pre-3.24 behavior where the gateway started without requiring an explicit mode. Fixes openclaw#54801 Co-authored-by: Brad Groux <[email protected]>
After v2026.3.24 introduced a
gateway.modeguard in the gateway run command, startup fails on Windows (and other platforms) when the config file exists but doesn't contain an explicitgateway.modevalue. This happens afteropenclaw onboardwrites a minimal config without gateway settings — the DOS window opens and immediately closes.Root cause:
effectiveCfg.gateway?.modeevaluates toundefinedwhen the config has nogatewaysection, causing themode !== "local"guard to block startup with exit code 1.Fix: Default
modeto"local"when unset, restoring pre-3.24 behavior where the gateway started without requiring an explicit mode.One-line change in
src/cli/gateway-cli/run.ts.Fixes #54801