mirror of
https://github.com/multica-ai/multica.git
synced 2026-08-04 17:18:35 +02:00
Addresses review on #6158. Recursive redaction ran only in the server's ingest handler. The daemon built the new nested edit payload and sent msg.Input verbatim, so a daemon that self-updated ahead of the server — or one talking to a server mid-rollout — would ship whole-file edit contents to a peer that does not scrub nested values yet. The legacy protocol reports a deletion as the whole outgoing file, so that window covered a deleted .env in cleartext. Ordering three commits inside one PR is not a deployment barrier, and daemon and server upgrade independently. Deployment order is not a control we have, so the sending side is now safe on its own; the server keeps redacting on ingest as the second line of defence. Scoped to Input, which is the field this PR newly fills with file contents. Content and Output are plain strings already redacted server-side, and changing their daemon-side handling would be unrelated to this fix. Verified: the new daemon test asserts the nested token is masked in the reported batch while the change metadata survives. It fails without this change, reporting the full GITHUB_TOKEN= line on the wire, and passes with it; ./internal/daemon green. Co-authored-by: multica-agent <github@multica.ai>