Every version, and what it changed for you.

macOS stops asking for your keychain password. A keychain entry passes two checks, and 0.46.0 only closed one of them: the other files every entry under the code signature of the binary that created it, so `chi`, `chi-mcp`, each release and each local build counted as different applications and each paid a password panel. Archis now keeps its credentials in its state directory instead, moves what is already in your keychain out — once, after telling you why — and afterwards cannot open that dialog at all.

Before you upgrade — Update. On macOS, then run any chi command from a terminal: it moves your credentials out of the keychain, which costs one password prompt and is the last one. A fresh installation pays none, and nothing has to be rebuilt.

• Improvedchi doctor says where this machine keeps its credentials and what decided it, and warns when a copy is still sitting in the keychain.
• ImprovedThe rules file is called .chignore. .chiignore had an i too many, and it was the name nobody typed right the first time. A project that already has one loses nothing and does nothing: the next chi index writes the new file with the same rules, each where it was, and only then deletes the old one.
• FixedThe macOS keychain no longer asks for your password. 0.46.0 made the entry trust every application, which is one of the two checks it passes; the other is the partition list, and macOS writes it as the signing identity of whoever created the entry — a cdhash, for the ad-hoc signature these binaries carry. chi and chi-mcp are therefore different applications to it, as is every new version, and widening that list is itself an authorization the password panel guards. So Archis stops using the keychain while its signature cannot keep an entry silent: credentials live in the state directory, at the same boundary as the file Archis already falls back to on a machine with no keystore. When the binaries are signed with a stable identity, the keychain comes back on its own.
• FixedNothing in Archis can open a keychain dialog any more, except the one-time move that says so first. A read that would have prompted now fails instead, and every caller already had somewhere to go. This was not only a dialog: keychain panels wait, so one opened by a hook or inside an editor's tool call — where nobody can see it — would sit there. One measured here sat for six and a half hours.
• FixedYour device key cannot be replaced by a new one while a copy of it sits somewhere Archis was not allowed to read. That would have left every encrypted index sealed to the old key unopenable until the next epoch. Archis now says what happened and what to run.
• Fixedchi uninstall --purge reported that it had removed this machine's identity from the keychain without checking, and skipped the keychain entirely when the state directory was already gone — though the entry belongs to the machine, not to the directory. It now asks either way and reports what it could not remove. chi auth logout reaches only entries that are actually there.