Release notes

BUGFIX

Removing usage preserves your status line, and unreadable hooks stop safely

If you kept your own terminal status line, removing the Codex line added by usage used to risk taking yours with it. Removal now compares the text exactly and touches only a line equal to CODEX_STATUS_LINE; if its backup is corrupt or has the wrong type, both the configuration and backup stay untouched. A second safeguard covers hooks (small programs triggered by particular events): when ~/.codex/hooks.json cannot be read, usage stops instead of treating it as empty and writing it back. That protects every hook and avoids leaving a half-installed state. It is like collecting rented coat hangers only after checking their labels; if you cannot see inside a locker, you leave it alone.

Original changelog

Original changelogRemoving usage preserves your status line, and unreadable hooks stop safely
**Removing the Codex status line no longer deletes one that `usage` never installed.** `_unsetup_codex()` only checked whether a `tui.status_line` existed at all, not whether it was ours. Anyone who had configured their own status line and then ran the removal lost it. Worse, a corrupt backup file made the restore path overwrite the config with an empty list and then delete the only backup, losing both at once. Removal now acts only when the status line matches `CODEX_STATUS_LINE` exactly, and an unreadable or wrong-typed backup leaves both the config and the backup untouched.
**A corrupt `~/.codex/hooks.json` is no longer treated as an empty one.** `_load_codex_hooks()` returned `{}` for "file missing" and "file exists but won't parse" alike; terse mode then rebuilt from that empty dict and wrote it back, permanently erasing every Codex hook the user had, with no backup and no message. Codex writing that file while `usage` reads it is enough to trigger this. The unreadable case now aborts before anything is copied or written, so a failed run can no longer leave a half-installed state either.