{"version":"2.1.238","anchor":"a-failed-backup-no-longer-aborts-corrupt-config-recovery","canonical_anchor":"a-failed-backup-no-longer-aborts-corrupt-config-recovery","heading":"A failed backup no longer aborts corrupt-config recovery","tier":"notice","area":"Configuration","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238\/e\/a-failed-backup-no-longer-aborts-corrupt-config-recovery","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238","markdown":"### A failed backup no longer aborts corrupt-config recovery\n\nRecovery from a corrupt ~\/.claude.json now continues even if backing up the broken file fails.\n\n**What**\n\nWhen `~\/.claude.json` is corrupt, a failure while backing up the broken file is now logged and recovery continues, instead of stopping there.\n\n**Details**\n\n- The message includes the underlying error text.\n- The watcher behind the config was also tightened: it now drops its freshness subscription if the storage backend changed underneath it, and ignores an update event that matches the version this process just loaded.\n- Its fallback log line now reads \"using the fs.watchFile poll\" rather than \"staying on\" it.\n\n**Evidence**\n\n`Could not back up corrupted config (`\n\n- Area: Configuration\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}