repair-session only ever listed the project you were standing in, which is a
poor place to start from when the thing you cannot resume is a session whose
project you no longer remember. --all drops the working-directory scoping and
checks all of them. (A named session id was already looked up across every
project; only the listing was scoped.)
The first version of that scan reported 16 of 59 transcripts as unresumable,
which was true in the narrowest sense and useless in every other. Checking them:
5 had never received an assistant reply at all, and 10 had run start to finish
on a gateway, so every id in them is that provider's by design. Those resume
perfectly well under the provider they were born on, have nothing to truncate
back to, and are only a problem if you try to resume them as Anthropic. Calling
either of them damage buries the one case that is.
So the verdict now carries a kind - healthy, repairable, gateway-native,
synthetic-only, no-messages - and only `repairable` is reported or acted on: a
transcript with a genuine msg_ message and junk after it. Across the same 59 it
now correctly reports nothing to repair, while still classifying the real
corrupted transcript from the incident as repairable with 108 lines to drop.
A gateway-native session asked about directly now says what it is and that there
is nothing to fix, rather than failing with "no Anthropic-issued message".
smoido
43cef6bf9e