← Back to PRs

#22408: fix: doctor --fix now persists config when removing unrecognized keys

by astroclaw open 2026-02-21 04:09 View on GitHub →
commands size: XS
## Summary Fixes #22272 When `doctor --fix` strips unknown config keys via `stripUnknownConfigKeys()`, the repaired config is correctly assigned to `cfg`, but `shouldWriteConfig` remains `false`. In `doctor.ts`, `cfgForPersistence` is cloned from `cfg` **after** `loadAndMaybeMigrateDoctorConfig` returns — so the JSON comparison finds no diff and the file is never written to disk. ## Root Cause In `doctor-config-flow.ts`, `shouldWriteConfig` is only set to `true` in the interactive (non-repair) path when the user confirms. In the `--fix` path, even though `pendingChanges` is `true` and `cfg` has been modified, `shouldWriteConfig` stays `false`. ## Fix Set `shouldWriteConfig = true` when `shouldRepair` is active and `pendingChanges` were made, ensuring the caller always writes the repaired config to disk. ## Testing 1. Add an unrecognized key to `~/.openclaw/openclaw.json` (e.g. `models.providers.anthropic.cacheRetention`) 2. Run `openclaw doctor --fix` 3. Verify the key is removed from the config file <!-- greptile_comment --> <h3>Greptile Summary</h3> Fixed a bug where `openclaw doctor --fix` would strip unrecognized config keys but fail to persist the changes to disk. The issue was that `shouldWriteConfig` remained `false` in the repair path, even though `pendingChanges` was `true` and `cfg` was modified. The fix adds a check after all config repairs are complete: if `shouldRepair` is active (from `--fix` or `--yes` flag) and `pendingChanges` is `true`, it sets `shouldWriteConfig = true`. This ensures the caller in `doctor.ts` writes the repaired config to disk via the comparison at line 288-289. The fix is minimal, well-placed, and directly addresses the root cause described in the PR description. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The fix is a simple, well-targeted boolean assignment that directly addresses the bug described in the issue. The logic is sound: when repair mode is active and changes were made, the config should be written. The placement is correct (after all repairs, before the return statement), and the fix doesn't introduce any side effects or change existing behavior for interactive mode. - No files require special attention <sub>Last reviewed commit: d5676e5</sub> <!-- greptile_other_comments_section --> <sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub> <!-- /greptile_comment -->

Most Similar PRs