Email Redaction on Vault Sync
An opt-in setting that removes email addresses from every file BlackOps commits to your connected repository.
Everything BlackOps writes to your vault becomes a git commit, and git commits are permanent — editing a file later removes content from the current version, but the original bytes stay in the repository's history forever. For most vaults that's exactly what you want: your notes are yours, and an address you write down on purpose should stay written down.
The calculus changes when a vault is shared. A repo with collaborators, a public vault, or a knowledge base that receives outside contributions (like brain share replies) can end up permanently storing other people's contact details. Email redaction exists for those vaults — and it's off by default.
Turning it on
Go to Settings → Knowledge Settings (alongside your Obsidian/GitHub connection settings) and enable Redact email addresses on vault sync. From that point, every file BlackOps commits to your repository is scanned on its way in — notes, brain notes, compiled manifests, share replies, everything. Your choice applies to the whole workspace.
With the setting off, nothing is ever altered: files commit exactly as written.
What redaction does
When the setting is on, email addresses in outgoing commits are replaced:
| Case | Committed as |
|---|---|
| Address is on your allowlist | Unchanged |
| Address belongs to a known contact (e.g. a brain share recipient) | {name} #{tag} — a stable, non-reversible identity tag |
| Anything else | [redacted] |
The contact tag is derived from a hash of the address: the same person always renders the same tag across notes, different people never collide, and the tag reveals nothing about the address itself. BlackOps deliberately avoids partial masking like a****y@gmail.com, which leaks the provider and enough shape to often reconstruct the address.
Detection is intentionally narrow — email addresses only. Technical content that merely looks like an address (GitHub machine addresses such as git@github.com, retina asset filenames like logo@2x.png) passes through untouched.
For brain share replies specifically, redaction also covers the two places file content can't reach: the generated filename and the git commit message, where the recipient renders as their name plus tag instead of their address.
Redaction is never silent
When the pass changes anything, the tool response says so:
"redaction": {
"applied": true,
"count": 1,
"kinds": ["email"],
"warning": "1 email address was redacted before committing to the vault"
}
This appears in the responses of post_notes, patch_notes, post_notes_write, and update_brain, alongside a matching warnings entry. You always know when a committed file differs from what you wrote.
Your data stays intact in BlackOps
Redaction applies to the synced file only. The record inside BlackOps keeps the full original content, and API and MCP responses return it in full. The distinction is persistence: a tool response is ephemeral, a git commit is forever.
Allowlist
Some addresses should stay in synced files even with redaction on: support@, hello@, a published business contact. Add them to the allowlist under the same setting — one entry per line, either a full address or a domain wildcard:
hello@yourcompany.com
*@yourcompany.com
Matching is case-insensitive.
What this does not do
- It does not clean git history. Redaction affects future commits only; anything committed before you turned it on remains in your repository's history.
- It does not detect phone numbers or physical addresses. Email only — broad "looks like PII" heuristics produce false positives that corrupt real content, which is worse than the problem.