v5.8.1

[5.8.1] — 2026-08-30

Fixed

• Closing the last chat no longer reports an internal error. Closing a chat that was the only one
  open, and that had been used, left the IDE logging Already disposed from the browser component the
  chat had just torn down. The chat's card is now hidden before it leaves the tool window, so the layout
  never lays out a browser that is already gone. Nothing about closing a chat changes for you: the
  replacement chat still opens as before.

---

Verifying this release. Both the .asc files and the tag are signed by the project's CI
signing key, and everything needed to check it is in the one file attached here as
trust-chain.asc: that key's public half, plus the two hardware CAs that certify it — so the
chain terminates in keys whose private halves have never been on a computer.

One file rather than three because a chain is imported whole or not at all. A certification you
have no way to follow is indistinguishable from one nobody made, which is exactly the assurance
the two CA keys carry.

What the signatures do NOT assert is that a human pressed a button: the release is cut
automatically from the merge into main, with no approval step and no required reviewer. What
stands behind it instead is mechanical, and it is worth being exact about — main accepts nothing
but pull requests that are up to date and have all nine required checks green (among them the JVM
and frontend tests, both CodeQL scans, the dependency audit and the plugin verifier), that
protection can be bypassed by nobody including admins, and this workflow refuses to publish a
commit that is not reachable from main or a version number that has already been released.

gpg --import trust-chain.asc
# The CI key is the LAST block in that file — the CAs come first, and the awk below takes the
# last one deliberately. Then: endorsed by both of them, not merely asserted by a file.
gpg --check-sigs "$(gpg --show-keys --with-colons trust-chain.asc \
                    | awk -F: '$1=="pub"{getline; if ($1=="fpr") f=$10} END{print f}')"
gpg --verify claude-code-native-*.zip.asc   # these bytes came from this workflow
git verify-tag <tag>                        # this workflow cut this release from main

The one check worth doing that this file cannot do for you. Everything above arrives from
this repository, so it proves the release is internally consistent and nothing more — whoever
could publish a forged artifact could publish a bundle agreeing with it. The CAs are therefore
also on keys.openpgp.org, an operator with no relation to GitHub, and fetching one by
fingerprint is what turns the chain into evidence:

gpg --keyserver hkps://keys.openpgp.org --recv-keys <CA fingerprint from SECURITY.md>

Two copies of the same CA from two unrelated publishers either agree, or the disagreement is
the story.