cc-safety-net. If you use an older version, upgrade before you report an issue unless the vulnerability also affects the latest release.
This page explains how to report an issue. For trust boundaries, fail-closed enforcement, and attack surface, see Security model. The canonical policy is SECURITY.md in the source repository.
A command that was not blocked is a public bug. Harmful behavior by CC Safety Net is a private vulnerability. If you are not sure which report you have, read Choose a public or private report. If you still need to diagnose the behavior, start at Troubleshooting.
Report a vulnerability privately
Do not report security vulnerabilities in public GitHub issues. Use GitHub private vulnerability reporting for the repository when available. If that is unavailable, email the maintainer at jliew@420024lab.com. Include this information when it is safe to share:- The affected
cc-safety-netversion - Your operating system and runtime version
- The affected integration, such as Claude Code, OpenCode, Gemini CLI, GitHub Copilot CLI, or Codex
- Steps to reproduce, and the command or input that bypasses, weakens, or abuses CC Safety Net
- Any relevant output from
cc-safety-net explainorcc-safety-net doctor - Whether the issue can cause data loss, command execution, secret exposure, or another concrete security impact
Choose a public or private report
CC Safety Net’s job is to stop agents from running destructive commands within the selected safety level’s documented guarantees. A report that the tool failed to do that job is a bug, and it belongs in a public GitHub issue. The strict and paranoid threat model assumes an attacker (prompt injection, adversarial context) can emit any destructive command, so publishing “this command shape is not caught” does not hand the attacker a capability they did not already have — it gets the gap fixed faster and lets users ship a custom rule as an immediate workaround. A report that the tool did something harmful it was never supposed to do — leak a secret, write a file outside its own directory, or ship a tampered package — is a vulnerability. The non-obvious construction is the secret, so it belongs in private disclosure. The dividing line is: did the tool fail to stop a destructive command, or did the tool itself become the harmful vector?What counts as a security issue
Report these privately:- Leakage of secrets through block messages, audit logs, diagnostics, debug output, or a false-positive report prefill, including a redaction bypass for a specific token format or a path the report preview claims to have replaced
- A path traversal or filesystem issue in audit logging or configuration handling, where crafted input writes outside the intended directory
- A supply-chain or packaging issue affecting the published npm package or plugin distribution, including rulebook integrity
What belongs in public issues instead
Use normal GitHub issues for:- Any bypass or fail-open that lets a destructive command execute — a coverage gap (a command the rules do not block yet), a parser, tokenizer, or wrapper-analysis edge case, or an analysis error that lets a command through instead of blocking it. Report the command shape, not a ready-to-paste weaponized prompt-injection payload.
- False positives where a safe command is blocked
- Missing convenience rules or new feature requests
- Documentation bugs
- Installation problems without a security impact
- Questions about custom rules or configuration
A destructive-command coverage gap stays public even when it looks severe. It is not reclassified as a vulnerability, and the private path is reserved for the categories listed above. A command allowed under standard mode’s documented relaxations is not a gap at all — standard is best-effort, and strict or paranoid is the level that fails closed on those forms.