Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Bug: unrecognized key in openclaw.json causes infinite gateway crash loop with no recovery [1 pull requests, 1 participants]

Official PRs (…)
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.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#57391•Fetched 2026-04-08 01:50:11
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
zeeyuu222zeeyuu222
Participants
zeeyuu222zeeyuu222
Timeline (top)
cross-referenced ×1referenced ×1

Adding an unrecognized key to openclaw.json (e.g., inside agents.list[]) causes the gateway to enter an infinite crash loop with no self-recovery. The only fix is manual config editing while the gateway is down.

The crash loop restarts every ~10 seconds and can run for hours before the user notices (700+ restarts in one incident).

Error Message

Option A (preferred): Validate before writing. When config changes are made via openclaw CLI commands, the gateway, or agents — validate the full config against the schema before persisting. Reject invalid changes with a clear error instead of writing them to disk.

  • The thinking key is particularly confusing because thinking is a valid OpenClaw concept — it's just configured at session level (/reasoning), not in agent config. The error message doesn't suggest where the setting actually belongs

Root Cause

  • openclaw doctor can detect and sometimes fix these issues, but only if the user knows to run it — which they can't discover while the gateway is crash-looping
  • openclaw config schema (new in 2026.3.28) helps users check valid fields, but doesn't prevent the crash
  • The thinking key is particularly confusing because thinking is a valid OpenClaw concept — it's just configured at session level (/reasoning), not in agent config. The error message doesn't suggest where the setting actually belongs

Fix Action

Fixed

PR fix notes

PR #57406: fix(gateway): stop restart loop after 3 consecutive startup failures

Description (problem / solution / changelog)

Summary

Unrecognized config keys cause the gateway to throw during startup. When supervised by systemd, this creates an infinite crash loop (700+ restarts observed) because each crash triggers a restart before systemd can detect the restart pattern.

Root Cause

In src/cli/gateway-cli/run.ts, the supervised restart loop only handled GatewayLockError as a retriable case. All other startup errors caused the process to throw and exit, triggering systemd's restart — creating an infinite loop.

Fix

Added a consecutive startup failure counter inside the supervised restart loop. After 3 consecutive non-GatewayLockError failures, the gateway logs a diagnostic message and exits cleanly instead of retrying forever:

Gateway failed to start 3 consecutive times. This may be caused by an invalid config.
To diagnose: run `openclaw gateway start --verbose` or `openclaw doctor`.
To fix config: edit ~/.openclaw/openclaw.json to remove or correct the invalid key.
Stopping restart loop to prevent resource exhaustion.

GatewayLockError retries are not counted as failures, so the lock-retry path remains unaffected.

Files Changed

  • src/cli/gateway-cli/run.ts

Linked Issue

Fixes #57391

Changed files

  • extensions/discord/src/monitor/provider.lifecycle.test.ts (modified, +39/-0)
  • extensions/discord/src/monitor/provider.lifecycle.ts (modified, +6/-0)
  • extensions/telegram/src/bot-handlers.media.ts (modified, +1/-1)
  • extensions/telegram/src/sequential-key.ts (modified, +12/-1)
  • packages/memory-host-sdk/src/host/session-files.test.ts (modified, +36/-0)
  • packages/memory-host-sdk/src/host/session-files.ts (modified, +6/-1)
  • src/agents/pi-tools.ts (modified, +5/-1)
  • src/agents/tool-policy.test.ts (modified, +24/-0)
  • src/agents/tool-policy.ts (modified, +19/-2)
  • src/cli/gateway-cli/run.ts (modified, +20/-2)

Code Example

{
  "agents": {
    "list": [
      {
        "id": "main",
        "thinking": "adaptive"
      }
    ]
  }
}

---

Invalid config at ~/.openclaw/openclaw.json: - agents.list.0: Unrecognized key: 'thinking'

---

FATAL: Invalid config. Run `openclaw doctor --fix` to attempt auto-repair, 
or manually edit ~/.openclaw/openclaw.json to remove the invalid key.
Gateway will not start until config is fixed.
RAW_BUFFERClick to expand / collapse

Summary

Adding an unrecognized key to openclaw.json (e.g., inside agents.list[]) causes the gateway to enter an infinite crash loop with no self-recovery. The only fix is manual config editing while the gateway is down.

The crash loop restarts every ~10 seconds and can run for hours before the user notices (700+ restarts in one incident).

Environment

  • OpenClaw: 2026.3.24 / 2026.3.28
  • OS: Linux (Ubuntu), systemd managed gateway
  • Gateway: local mode

Steps to Reproduce

  1. Add any unrecognized key to an agent entry in openclaw.json:
{
  "agents": {
    "list": [
      {
        "id": "main",
        "thinking": "adaptive"
      }
    ]
  }
}
  1. Gateway crashes immediately on startup:
Invalid config at ~/.openclaw/openclaw.json: - agents.list.0: Unrecognized key: 'thinking'
  1. systemd auto-restarts the gateway → crash → restart → crash → infinite loop.

A similar crash occurs with an incomplete provider block (e.g., missing required baseUrl or models fields).

Expected Behavior

Option A (preferred): Validate before writing. When config changes are made via openclaw CLI commands, the gateway, or agents — validate the full config against the schema before persisting. Reject invalid changes with a clear error instead of writing them to disk.

Option B: Graceful degradation. On startup, if config validation fails on non-critical fields, log a warning and ignore the unrecognized keys instead of crashing. Only crash on truly unrecoverable errors (e.g., missing gateway bind address).

Option C: Recovery hint. If crashing is intentional for invalid config, surface the fix command prominently in logs:

FATAL: Invalid config. Run `openclaw doctor --fix` to attempt auto-repair, 
or manually edit ~/.openclaw/openclaw.json to remove the invalid key.
Gateway will not start until config is fixed.

And critically: stop the restart loop after N consecutive failures (e.g., 3) to avoid burning resources and log space.

Additional Context

  • openclaw doctor can detect and sometimes fix these issues, but only if the user knows to run it — which they can't discover while the gateway is crash-looping
  • openclaw config schema (new in 2026.3.28) helps users check valid fields, but doesn't prevent the crash
  • The thinking key is particularly confusing because thinking is a valid OpenClaw concept — it's just configured at session level (/reasoning), not in agent config. The error message doesn't suggest where the setting actually belongs

Impact

  • Any config typo or misplaced key causes total gateway downtime
  • systemd restart loop burns CPU and fills logs (~700 restarts = ~2 hours before manual intervention)
  • Users experimenting with config (or agents modifying config) can accidentally take down the entire system
  • No notification is sent to the user during the crash loop — the system is silently dead

extent analysis

Fix Plan

To address the issue, we will implement Option B: Graceful degradation. We will modify the configuration validation to ignore unrecognized keys instead of crashing.

Step-by-Step Solution

  1. Update the configuration validation function:

import jsonschema

def validate_config(config): schema = { "type": "object", "properties": { "agents": { "type": "object", "properties": { "list": { "type": "array", "items": { "type": "object", "properties": { "id": {"type": "string"} }, "required": ["id"] } } }, "required": ["list"] } }, "required": ["agents"] }

try:
    jsonschema.validate(instance=config, schema=schema)
except jsonschema.exceptions.ValidationError as err:
    # Log a warning and ignore unrecognized keys
    print(f"Warning: Invalid config - {err}")
    # Remove unrecognized keys from the config
    config = remove_unrecognized_keys(config, schema)
    return config
return config

def remove_unrecognized_keys(config, schema): # Recursively remove unrecognized keys from the config if isinstance(config, dict): return {key: remove_unrecognized_keys(value, schema.get("properties", {})) for key, value in config.items() if key in schema.get("properties", {})} elif isinstance(config, list): return [remove_unrecognized_keys(item, schema.get("items", {})) for item in config] return config

2. **Modify the gateway startup script** to use the updated validation function:
   ```python
import json

def load_config():
    with open("~/.openclaw/openclaw.json", "r") as f:
        config = json.load(f)
    return validate_config(config)

def main():
    config = load_config()
    # Start the gateway with the validated config
    start_gateway(config)
  1. Implement a restart limit to prevent infinite crash loops:

import sys

def main(): max_restarts = 3 restarts = 0 while restarts < max_restarts: try: config = load_config() start_gateway(config) break except Exception as e: print(f"Error starting gateway - {e}") restarts += 1 if restarts == max_restarts: print("Maximum restarts reached. Please check the config and try again.") sys.exit(1)


### Verification
To verify the fix, add an unrecognized key to the `openclaw.json` file and restart the gateway. The gateway should log a warning and ignore the unrecognized key instead of crashing.

### Extra Tips
* Use a linter or

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?
Loading…
#search optimization#API routing#API middleware#SSR setup#ISR setup

Still need to ship something?

×6

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

Back to top recommendations

TRENDING