openclaw - ✅(Solved) Fix Update 2026.4.9 → 4.11 silently wipes channels.discord config and agents.list from openclaw.json [1 pull requests, 1 comments, 2 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#65105Fetched 2026-04-12 13:25:33
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Author
Timeline (top)
commented ×1cross-referenced ×1

Updating OpenClaw through versions 2026.4.9 → 4.10 → 4.11 silently destroyed critical configuration: the entire channels.discord block and the agents.list array were wiped from openclaw.json. All four automatic backup files (.bak through .bak.3) were also missing this data, leaving no local recovery path. Additionally, gateway.mode became a required field at some point during the update chain but was never set by the update process or by openclaw onboard --mode local, blocking gateway startup entirely until manually set.

None of these issues are documented in the changelogs for 2026.4.10 or 2026.4.11.

Error Message

  1. Validate config preservation: After an update's config migration, diff the old and new configs and warn (or abort) if critical top-level keys like channels.* or agents.list were removed.

Root Cause

Updating OpenClaw through versions 2026.4.9 → 4.10 → 4.11 silently destroyed critical configuration: the entire channels.discord block and the agents.list array were wiped from openclaw.json. All four automatic backup files (.bak through .bak.3) were also missing this data, leaving no local recovery path. Additionally, gateway.mode became a required field at some point during the update chain but was never set by the update process or by openclaw onboard --mode local, blocking gateway startup entirely until manually set.

None of these issues are documented in the changelogs for 2026.4.10 or 2026.4.11.

Fix Action

Fixed

PR fix notes

PR #65113: doctor: warn about orphaned agent dirs

Description (problem / solution / changelog)

Summary

  • Problem: openclaw doctor did not warn when ~/.openclaw/agents/<id>/agent directories still existed on disk but the matching agents.list[] entries were missing from config.
  • Why it matters: a partially lost config can leave agent state on disk while routing, identity, and model selection ignore those agents, which makes recovery confusing.
  • What changed: the state-integrity doctor pass now scans on-disk agent directories and warns when they no longer have matching agents.list[] entries.
  • What did NOT change (scope boundary): this PR does not reconstruct missing agent config automatically or change the already-fixed backup/update recovery paths from #65105.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #
  • Related #65105
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: doctor only checked general state/session integrity and never compared on-disk agent directories against configured agents.list[] entries.
  • Missing detection / guardrail: no doctor warning existed for orphaned agent directories, even though some runtime surfaces can still discover agents from disk.
  • Contributing context (if known): the original report in #65105 described agent directories remaining on disk after config loss, but doctor did not flag that mismatch.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/commands/doctor-state-integrity.test.ts
  • Scenario the test should lock in: doctor warns for real orphaned ~/.openclaw/agents/<id>/agent directories, but ignores configured agents and incomplete folders.
  • Why this is the smallest reliable guardrail: the new behavior is isolated to the doctor state-integrity scan and can be exercised deterministically with a temp state dir.
  • Existing test that already covers this (if any): none
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

  • openclaw doctor now warns when agent state directories exist on disk without matching agents.list[] entries in config.

Diagram (if applicable)

Before:
[config loses agents.list entries] -> [agent dirs still exist on disk] -> [doctor stays silent]

After:
[config loses agents.list entries] -> [agent dirs still exist on disk] -> [doctor warns about orphaned agent dirs]

Security Impact (required)

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS 26.3.0
  • Runtime/container: Node 25 / pnpm workspace
  • Model/provider: N/A
  • Integration/channel (if any): doctor CLI
  • Relevant config (redacted): config with only agents.list: [{ id: "main", default: true }] plus extra on-disk agent dirs under ~/.openclaw/agents/

Steps

  1. Create ~/.openclaw/agents/big-brain/agent and ~/.openclaw/agents/cerebro/agent in a temp state dir.
  2. Run noteStateIntegrity() with config that only defines main in agents.list.
  3. Inspect the emitted doctor state-integrity text.

Expected

  • Doctor warns that on-disk agent directories exist without matching agents.list[] entries.

Actual

  • Doctor now emits that warning and includes example agent ids.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios: targeted regression test for orphaned agent detection; targeted regression test for configured-agent and incomplete-folder false positives; repo-wide pnpm check.
  • Edge cases checked: default agent remains ignored; incomplete ~/.openclaw/agents/<id> folders without nested agent/ do not warn.
  • What you did not verify: full end-to-end recovery from a historical config wipe; pnpm build is currently failing in the existing tree due to an unrelated extensions/acpx/src/runtime.ts export-resolution error.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Migration needed? (No)
  • If yes, exact upgrade steps:

Risks and Mitigations

  • Risk: stale non-agent directories under ~/.openclaw/agents/ could be mistaken for orphaned agents.
    • Mitigation: the warning only considers directories that contain the nested agent/ runtime dir, and tests cover the incomplete-folder false-positive case.

AI assistance: prepared with an agent, with the code path, tests, and verification reviewed before submission.

Made with Cursor

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/commands/doctor-state-integrity.test.ts (modified, +115/-0)
  • src/commands/doctor-state-integrity.ts (modified, +94/-1)

Code Example

openclaw config set gateway.mode local

---

openclaw gateway install --force

---

{
  "gateway": {
    "auth": {
      "mode": "token",
      "token": "<redacted>"
    },
    "mode": "local"
  },
  "wizard": {
    "lastRunAt": "2026-04-12T00:19:24.558Z",
    "lastRunVersion": "2026.4.9",
    "lastRunCommand": "doctor",
    "lastRunMode": "local"
  },
  "meta": {
    "lastTouchedVersion": "2026.4.11",
    "lastTouchedAt": "2026-04-12T01:40:46.598Z"
  },
  "agents": {
    "defaults": {
      "models": {
        "claude-cli/claude-sonnet-4-6": {},
        "claude-cli/claude-opus-4-6": {},
        "claude-cli/claude-opus-4-5": {},
        "claude-cli/claude-sonnet-4-5": {},
        "claude-cli/claude-haiku-4-5": {}
      }
    }
  },
  "auth": {
    "profiles": {
      "anthropic:claude-cli": {
        "provider": "claude-cli",
        "mode": "oauth"
      }
    }
  },
  "plugins": {
    "entries": {
      "anthropic": {
        "enabled": true
      }
    }
  }
}

---

~/.openclaw/agents/main/agent/        — auth-profiles.json, models.json (has codex provider with gpt-5.4)
~/.openclaw/agents/big-brain/agent/   — models.json only (ollama gemma4:31b-cloud, no claude-cli provider)
~/.openclaw/agents/cerebro/agent/     — auth-profiles.json (empty profiles {}), models.json (ollama gemma4:31b-cloud)
~/.openclaw/agents/dr-feelgood/agent/ — models.json only (ollama gemma4:31b-cloud, no claude-cli provider)
RAW_BUFFERClick to expand / collapse

Summary

Updating OpenClaw through versions 2026.4.9 → 4.10 → 4.11 silently destroyed critical configuration: the entire channels.discord block and the agents.list array were wiped from openclaw.json. All four automatic backup files (.bak through .bak.3) were also missing this data, leaving no local recovery path. Additionally, gateway.mode became a required field at some point during the update chain but was never set by the update process or by openclaw onboard --mode local, blocking gateway startup entirely until manually set.

None of these issues are documented in the changelogs for 2026.4.10 or 2026.4.11.

Environment

  • OS: macOS 26.3.1 (arm64, Mac mini)
  • Node: 25.9.0
  • OpenClaw version: 2026.4.11 (769908e)
  • Install method: pnpm (Homebrew Node)
  • Gateway mode: local (loopback, 127.0.0.1:18789)
  • Update path: 2026.4.9 → 2026.4.10 → 2026.4.11

What broke

1. channels.discord completely removed from config

After the update chain, openclaw config get channels.discord returns Config path not found: channels.discord. The openclaw status Channels table is completely empty. Discord slash commands return "The application did not respond." The Discord bot, server, and bot token all still exist on Discord's side — this is purely a config-side wipe.

Expected: Update should preserve existing channel configuration, or at minimum the backup files should contain the pre-update state.

Actual: Channel config gone. All four .bak files are also missing the channels.discord block, meaning the backup rotation happened after the wipe — so the backups captured the already-broken state instead of the pre-update state.

2. agents.list array completely removed from config

The agents.list array (which declared multiple agents with their workspaces, model assignments, identities, and routing bindings) was entirely wiped. openclaw agents list now only returns main (the implicit default). Three other agents — big-brain, cerebro, dr-feelgood — still exist as directory trees under ~/.openclaw/agents/ with intact session history, auth profiles, and model provider catalogs, but OpenClaw no longer knows they exist as configured agents.

openclaw status still enumerates all four agents in the heartbeat line (scanning directories on disk), but they have no agents.list[] entries, so:

  • No per-agent model assignment → they fall back to whatever provider is first in their local models.json (in this case gemma4:31b-cloud via Ollama instead of the intended claude-cli/claude-opus-4-6)
  • No routing bindings → no channel traffic reaches them
  • No identity config → names/avatars/themes lost

The current openclaw.json only contains agents.defaults (with model catalog entries like claude-cli/claude-opus-4-6), but no agents.list at all.

3. gateway.mode became required but was never set

After the update, the gateway refused to start. The fix was:

openclaw config set gateway.mode local

Neither the update process nor openclaw onboard --mode local set this field. openclaw doctor did not flag it as missing either — it ran clean after the field was manually added, but the missing field was the actual blocker.

4. Gateway entrypoint stale after update

The gateway service was pointing at a stale entrypoint (entry.js instead of index.js). Fixed with:

openclaw gateway install --force

This should have been handled by the update process.

Backup files are useless for recovery

All four backup files show the progression of the post-wipe config being touched by different update steps. None contain the pre-update channels.discord or agents.list data:

FilelastTouchedVersionHas channels.discord?Has agents.list?
.bak.32026.4.9NoNo
.bak.22026.4.10NoNo
.bak.12026.4.10NoNo
.bak2026.4.10NoNo
openclaw.json2026.4.11NoNo

This means the backup rotation ran after the config was already wiped, so the pre-update state was never preserved. The backup mechanism is supposed to protect against exactly this scenario but failed to do so.

What openclaw doctor and openclaw onboard missed

  • openclaw doctor runs clean with zero errors even though Discord is completely unconfigured and three agents are orphaned on disk.
  • openclaw onboard did not set gateway.mode despite being run with --mode local.
  • Neither tool detected or warned about the orphaned agent directories under ~/.openclaw/agents/ that have no corresponding agents.list[] entries.

Recovery steps required

Full manual rebuild was necessary:

  1. openclaw config set gateway.mode local — unblock gateway startup
  2. openclaw gateway install --force — fix stale entrypoint
  3. Re-register channels.discord from scratch (token, enabled, guild allowlist, user allowlist) — no values recoverable from backups
  4. Re-create agents.list[] entries for big-brain, cerebro, dr-feelgood with correct model assignments (claude-cli/claude-opus-4-6), workspace paths, and routing bindings — no values recoverable from backups
  5. Copy auth-profiles.json into agent dirs that lost theirs (e.g., cerebro and dr-feelgood had empty profiles)
  6. Restart gateway and re-verify with openclaw channels status --probe

Suggestions

  1. Backup before destructive config writes: The backup rotation should snapshot openclaw.json before the update touches it, not after. Consider writing a timestamped backup (e.g., openclaw.json.pre-update-2026.4.10) before any config migration runs.
  2. Validate config preservation: After an update's config migration, diff the old and new configs and warn (or abort) if critical top-level keys like channels.* or agents.list were removed.
  3. Doctor should detect orphaned agents: If ~/.openclaw/agents/<id>/ directories exist but have no agents.list[] entry, doctor should flag this as a warning with a suggested fix.
  4. Doctor should detect missing channel config: If a channel directory or session history exists but channels.<channel> is absent from config, flag it.
  5. gateway.mode migration: If gateway.mode became required in 4.10 or 4.11, the update migration should set it based on the existing config (e.g., infer local from gateway.bind being loopback).
  6. Document breaking changes: If config schema changes require manual intervention, document them in the changelog with explicit migration steps.

Related config state

<details> <summary>Current openclaw.json (post-manual-fixes, still missing channels + agents.list)</summary>
{
  "gateway": {
    "auth": {
      "mode": "token",
      "token": "<redacted>"
    },
    "mode": "local"
  },
  "wizard": {
    "lastRunAt": "2026-04-12T00:19:24.558Z",
    "lastRunVersion": "2026.4.9",
    "lastRunCommand": "doctor",
    "lastRunMode": "local"
  },
  "meta": {
    "lastTouchedVersion": "2026.4.11",
    "lastTouchedAt": "2026-04-12T01:40:46.598Z"
  },
  "agents": {
    "defaults": {
      "models": {
        "claude-cli/claude-sonnet-4-6": {},
        "claude-cli/claude-opus-4-6": {},
        "claude-cli/claude-opus-4-5": {},
        "claude-cli/claude-sonnet-4-5": {},
        "claude-cli/claude-haiku-4-5": {}
      }
    }
  },
  "auth": {
    "profiles": {
      "anthropic:claude-cli": {
        "provider": "claude-cli",
        "mode": "oauth"
      }
    }
  },
  "plugins": {
    "entries": {
      "anthropic": {
        "enabled": true
      }
    }
  }
}
</details> <details> <summary>Orphaned agent directories on disk</summary>
~/.openclaw/agents/main/agent/        — auth-profiles.json, models.json (has codex provider with gpt-5.4)
~/.openclaw/agents/big-brain/agent/   — models.json only (ollama gemma4:31b-cloud, no claude-cli provider)
~/.openclaw/agents/cerebro/agent/     — auth-profiles.json (empty profiles {}), models.json (ollama gemma4:31b-cloud)
~/.openclaw/agents/dr-feelgood/agent/ — models.json only (ollama gemma4:31b-cloud, no claude-cli provider)
</details>

extent analysis

TL;DR

To fix the issue, manually rebuild the configuration by setting gateway.mode, re-registering channels.discord, and re-creating agents.list entries, and consider implementing a more robust backup and validation process to prevent similar issues in the future.

Guidance

  1. Manually set gateway.mode: Run openclaw config set gateway.mode local to unblock gateway startup.
  2. Re-register channels.discord: Manually reconfigure the Discord channel settings, including token, enabled status, guild allowlist, and user allowlist.
  3. Re-create agents.list entries: Manually reconfigure the agents.list array, including model assignments, workspace paths, and routing bindings for each agent.
  4. Implement robust backup and validation: Consider modifying the backup rotation to snapshot openclaw.json before updates and implementing config validation to detect and warn about critical changes.

Example

No code snippet is provided as the issue requires manual configuration changes.

Notes

The provided issue lacks information on the exact update process and the expected behavior of the openclaw tool. The suggested fixes are based on the information provided and may not be comprehensive.

Recommendation

Apply a workaround by manually rebuilding the configuration and implementing a more robust backup and validation process to prevent similar issues in the future. This is recommended because the issue is caused by a silent destruction of critical configuration data during the update process, and a more robust backup and validation process can help prevent similar issues.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING