Commit Graph
3 Commits
Author SHA1 Message Date
bvandeusenandClaude Opus 5 fe2f88cdb6 fix(telemetry): migration 0099 matched inside words and mangled rows (#3925)
CI & Build / Python lint (push) Successful in 4s
CI & Build / Plugin hooks (push) Successful in 11s
CI & Build / integration (push) Successful in 49s
CI & Build / TypeScript typecheck (push) Successful in 55s
CI & Build / Python tests (push) Successful in 1m26s
CI & Build / Build & push image (push) Successful in 24s
Found post-deploy, by reading the telemetry it had just rewritten.

The token it was written for IS gone — `TOK=[redacted:token]` where a
credential used to be. But `<task-notification>` came back as
`<ta[redacted:token]>`, across rows, because `sk-` matched INSIDE the word:
`sk-` + `notification` is a vendor prefix followed by twelve word characters.

TWO PORTING MISTAKES, COMPOUNDED. The live scrubber's pattern begins with
`\b`; the migration's inlined copy had no boundary at all, dropped when I
ported it to SQL. And `\b` would not have saved it either — in Postgres ARE
`\b` is a BACKSPACE, not a word boundary. `\m` (start of word) is the
spelling that means what Python's `\b` means. Two things that look
interchangeable, are not, and fail in the same direction.

The live scrubber was never affected, and the evidence says so cleanly: rows
written after the deploy carry `<task-notification>` intact, while
migration-rewritten ones are mangled. Only the frozen copy was wrong.

THE DAMAGE HERE IS PERMANENT. The UPDATE overwrote the only copy of that
text, so those rows cannot be restored. What this fixes is every OTHER
install: 0099 has run exactly once, on one instance, and shipping a known
evidence-destroying migration in the chain for everyone else would be the
worse half of the mistake. The docstring records what it cost rather than
tidying it away.

The guard pins the property no reader can eyeball — `\m` present, `\b`
absent, in both patterns — and is falsified against the shape that shipped.

This is the third time this scrubber has eaten evidence it should not have
(`--author=`, then `task-notification`), and the pattern is consistent: the
redaction half is easy to verify and the SURVIVAL half only fails on inputs
I did not think to include. The evidence set is where the work is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011cPyzNnegXHr5iRMzzy5KJ
2026-09-11 20:11:43 -04:00
bvandeusen 18e3cf9f2f fix(telemetry): scrub existing rows, and stop --author= being eaten (#3925) 2026-09-11 15:43:31 -04:00
bvandeusenandClaude Opus 5 bfa2d419f9 fix(telemetry): a logged query never carries a credential (#3925)
pre_tool_rule retrieves against the RAW COMMAND TEXT and write_path_rule
against the code being written, so whatever was on the command line or in
the buffer is what record_retrieval stored in retrieval_logs.query. A
command that exported a token stored the token.

Storing it was not the worst of it. near_miss_samples is the readout the
threshold docs tell you to open before moving a bar, so the value came back
OUT into an agent's context on the next tuning pass — which is exactly how
this was found, mid-way through #3853's threshold spike.

SCRUBBED ON WRITE, at _build_payload — the single seam every source reaches
the column through. A read-side filter would leave the secret in the table
where a backup or a debug query still reaches it, and a per-caller scrub
would be three places for one to be forgotten by whoever adds the fourth
arm.

REDACTED VISIBLY. `[redacted:<kind>]` rather than a silent deletion: a
reader who cannot tell a scrubbed query from a short one is being lied to
by the readout itself.

DELIBERATELY CONSERVATIVE — vendor-prefixed credentials, values assigned to
secret-NAMED variables, auth headers, PEM blocks. Things that are secrets by
construction. Entropy heuristics and long-opaque-string detection start
eating real queries, and a query is evidence: missing an exotic secret costs
one redaction nobody made, while eating a query costs the ability to tune
the bar at all.

The guard pins BOTH directions, and the second half is the one that matters.
A scrubber that eats evidence fails silently — it keeps looking like it
works while turning the one instrument for tuning a threshold into
unreadable stubs, which is the #2663 shape in a new place. So nine REAL
queries from this install's near-miss samples must survive byte for byte. If
a future pattern touches one, the pattern is too greedy.

Verified against the real shapes before commit: six credential formats
redacted (fabricated values), nine real queries unchanged, and the payload
seam confirmed to store "export API_TOKEN=[redacted:assigned] && git push".

This does NOT scrub rows already written. Purging those is separate.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011cPyzNnegXHr5iRMzzy5KJ
2026-09-11 15:38:40 -04:00