chat-recall-securitylisted

# Security findings with chat-recall Every session chat-recall indexes is scanned for credentials. Secrets are masked on the machine before anything is sent, so these tools report a REDACTED preview and where it appeared, never the secret itself. Treat a finding as an incident until it is closed. A key in an old transcript is still a live key. ## Start here `mcp__chat-recall__recall_security_summary` — the action-required list: distinct leaked secrets grouped by redacted preview, per-detector totals and the top rules. This is the answer to "do we have any leaked secrets", "what should I rotate", "security findings". Read the grouping before reacting. One key pasted into nine sessions is ONE incident with nine occurrences, not nine problems, and rotating it closes all of them. ## Then narrow to a session `mcp__chat-recall__recall_security_session` — the findings for one session id: which lines matched which detector. Use it after `recall_security_summary` or after `recall_search` when the user asks "where did that come from" or needs to see the context a key was pasted into. ## Then close the loop `mcp__chat-recall__recall_security_dismiss` — mark a finding `rotated`, `false_positive` or `dismissed`. The dismissal syncs across devices. Choose the status honestly, because it is what a later scan trusts: - `rotated` — the credential was actually replaced. The old value is now dead. - `false_positive` — it never was a secret (an example key, a fixture, a hash that ma