Tell it what is sensitive
pii-airlock does not know your business. It may flag your own company name as a person, or miss an internal code name. Two short commands fix both.
Stop a false alarm: allow
pii-airlock allow "Acme SA"From now on "Acme SA" is never treated as personal data in this project. Good candidates: your company, your products, public figures you write about.
Always hide something: deny
pii-airlock deny "Project Phoenix" --as CODENAME"Project Phoenix" is now always hidden, as a placeholder labelled CODENAME. Good for client names, internal projects and anything the detector would not recognise by itself.
This project or everything?
By default a rule applies to the project you are in. Add --scope user to apply it everywhere.
pii-airlock allow "Jane Roe" --scope user # your own name, in all projectsSee what is in force
pii-airlock policy showIt prints the rules that apply right now and where each came from.
Create a policy file for a project
pii-airlock policy initThis creates .claude/skills/pii-airlock/SKILL.md. Claude Code reads it as instructions about handling personal data, and pii-airlock reads the settings block inside it. It is a normal text file you can edit and share with your team.
allow_list: [Acme SA]
deny_list:
CODENAME: [Project Phoenix]
custom_patterns:
- {entity: CONTRACT_ID, regex: 'CT-\d{6}'}custom_patterns hides anything that matches a pattern. The example hides contract numbers like CT-123456.
Where settings live
pii-airlock combines several layers. Later ones win:
- Built-in defaults
- Your personal file
~/.config/pii-airlock/config.yaml - A project file
.pii-airlock.yaml - A project policy
.claude/skills/pii-airlock/SKILL.md - Command-line options
Allow lists, deny lists and custom patterns add up across layers. Every other setting is replaced by the later layer.
Trusting a project you downloaded
A project's settings can loosen protection, for example by allowing a name. So for a repository you did not write, pii-airlock only applies the settings that tighten protection until you say otherwise.
After reading the project's policy files, accept them:
pii-airlock trustDo this again after a git pull that changes them. pii-airlock policy show tells you what is currently being ignored. Your own rules in ~/.config/pii-airlock/config.yaml are always trusted.