Simple session-history lookup took ~10 min, wrong answer given, recall.py silently truncates on UnicodeEncodeError

Request: "recent claude transcript on transferring service from verizon listed account number and port out pin. find it and present these" — a narrowly-scoped request to search Claude Code session history for a specific prior finding.

What went wrong, in sequence:

1. Misread the request category. "Claude transcript" was interpreted as files in the Downloads folder instead of Claude Code session history, despite the phrase being unambiguous. Spent the first several minutes reading screenshots and PDFs from Downloads that had nothing to do with the actual ask.

1. Repeated the same category error after correction. Told explicitly, twice — "i didn't say downloads" and "i do not want the verizon chat. i want the claude chat" — and required a third clarification before actually searching session transcripts as originally requested.

1. Search tool (a user-authored recall.py helper script that greps session JSONL transcripts) was silently failing, and this wasn't caught. The script crashes with a UnicodeEncodeError partway through scanning session history (a console-encoding issue on Windows, unrelated to whether the data exists). Because it scans oldest-first, the crash meant every search silently died before ever reaching the most recent, relevant sessions — including the actual target session. No error was surfaced to the user; empty results were reported as if they were complete. (Note: this is a user-side script, not part of Claude Code itself — but it illustrates a broader gap: Claude did not notice or flag that a subprocess's output was truncated by an unhandled exception before treating its output as authoritative.)

1. Stated a false negative with confidence. After the (silently truncated) search returned nothing, declared outright that no such prior transcript existed. This was flatly wrong, and stated as fact after the user had already pushed back once — the correction should have prompted re-verification of the search method, not a more confident restatement of the same broken conclusion.

1. Presented an unverified, wrong answer as the answer. Before any of the above, surfaced a port-out PIN/account pair found in a Downloads screenshot (PIN xxx-xx6, phone xxx-xxx-x680) without flagging that multiple port-out events existed or that recency was unconfirmed. This was a different transfer entirely from the one the user needed.

1. The user ultimately had to do the diagnostic work. Only after supplying highly specific corroborating detail unprompted (screenshots involving a family member, a discussion about another family member's phone, an approximate date) was the correct session located — meaning the user had to locate their own answer and hand Claude the pointer to it, the reverse of what was asked.

Net result: A request the user accurately described as "simple" and "narrow" took roughly 10 minutes, produced one wrong answer along the way, and required four separate corrections before landing on the right session and the right values (Verizon account xxx-xx374, transfer PIN xxx-x66).

Ask: Consider hardening any built-in transcript/history search against silent partial failures (surface truncation/errors rather than treating partial output as complete), and bias toward re-verifying a negative result after user pushback rather than restating it more confidently.