Summary
ContainmentGuard.hook.ts ships in the public release at hooks/ContainmentGuard.hook.ts, but it contains hardcoded references to your personal infrastructure that make it unusable for anyone else. It looks like personal release-pipeline tooling that leaked into the public tree.
Details
The hook is a PreToolUse Edit/Write/MultiEdit gate that blocks writes containing any of these strings outside Z1-Z4 containment zones (USER/**, settings*.json, PAI/MEMORY/**, skills/_*):
/Users/daniel
daniel@
kai@unsupervised-learning
danielmiessler.com
admin.ul.live
889c0252fcc9f919765fa9f62467d46e # CF account ID
0baeb281c44f46878a4650ee3ff26b5b # CF KV namespace ID
The patterns are a readonly string[] literal in the hook source — there's no config file, env var, or override mechanism. The docstring also references ShadowRelease, which appears to be your internal release-staging pipeline.
For any user other than you:
- The hook never fires (none of these strings appear in their content)
- Registering it is a pure no-op
- The two Cloudflare IDs being committed publicly is also worth a glance — they're presumably non-secret routing identifiers, but it's worth confirming
Suggested options
Pick whichever fits your release workflow:
- Remove from public release. Treat it as internal tooling that lives only in your working tree, not the shipped tarball.
- Generalize. Move the pattern list to a user-editable config file (e.g.
USER/SECURITY/CONTAINMENT_PATTERNS.yaml) so each fork-holder can use it for their own identity strings. The Z1-Z4 containment-zone logic in lib/containment-zones.ts looks generic enough to keep.
- Rename + document as internal-only. Something like
_internal/ShadowReleaseGuard.hook.ts with a header making it clear it's not for end users. Less ideal because the public tree still ships your account IDs.
Happy to PR option 2 if that direction is useful — it's the same lib/containment-zones.ts machinery, just with patterns sourced from a YAML.
Context
Found this while auditing dormant hooks in my fork (PR #1200) — ContainmentGuard.hook.ts and CheckpointPerISC.hook.ts were the two undocumented hooks in the v5.0.0 release. CheckpointPerISC turned out to be a real opt-in feature; this one looks like accidental leakage of personal tooling.
Summary
ContainmentGuard.hook.tsships in the public release athooks/ContainmentGuard.hook.ts, but it contains hardcoded references to your personal infrastructure that make it unusable for anyone else. It looks like personal release-pipeline tooling that leaked into the public tree.Details
The hook is a
PreToolUseEdit/Write/MultiEdit gate that blocks writes containing any of these strings outside Z1-Z4 containment zones (USER/**,settings*.json,PAI/MEMORY/**,skills/_*):The patterns are a
readonly string[]literal in the hook source — there's no config file, env var, or override mechanism. The docstring also referencesShadowRelease, which appears to be your internal release-staging pipeline.For any user other than you:
Suggested options
Pick whichever fits your release workflow:
USER/SECURITY/CONTAINMENT_PATTERNS.yaml) so each fork-holder can use it for their own identity strings. TheZ1-Z4containment-zone logic inlib/containment-zones.tslooks generic enough to keep._internal/ShadowReleaseGuard.hook.tswith a header making it clear it's not for end users. Less ideal because the public tree still ships your account IDs.Happy to PR option 2 if that direction is useful — it's the same
lib/containment-zones.tsmachinery, just with patterns sourced from a YAML.Context
Found this while auditing dormant hooks in my fork (PR #1200) —
ContainmentGuard.hook.tsandCheckpointPerISC.hook.tswere the two undocumented hooks in the v5.0.0 release. CheckpointPerISC turned out to be a real opt-in feature; this one looks like accidental leakage of personal tooling.