v6.0.1

[6.0.1] — 2026-09-22

Fixed

• find_symbols no longer fails outright in Rider. A contributor that refuses the platform's
  processNames call — which Rider's do, because its symbols live in the ReSharper backend and are
  served only over its own protocol — is skipped instead of taking the whole tool down with
  UnsupportedOperationException: Use RdChooseByNameContributor.processNamesLifetimed. An answer
  reached by asking fewer contributors than the IDE has carries refused and contributors, and when
  it is also empty it carries a note, so an empty list is not read as an absent symbol or a stale
  index. Only when every contributor refuses does the tool fail, naming what does work there
  (search_text, find_files, file_outline, definition, references, implementations).

---

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.