Skip to content

v2.5.2

Latest

Choose a tag to compare

@github-actions github-actions released this 03 Oct 10:10

This release closes three analyzer bypasses that let destructive commands run, and adds CC_SAFETY_NET_PROJECT_TIGHTEN_ONLY=1 so a project policy can only tighten your own. The rule IDs reported for policy-config, policy-apply, and Git-metadata denials were renamed.

Highlights

  • Added CC_SAFETY_NET_PROJECT_TIGHTEN_ONLY=1, which makes a cloned repository's .cc-safety-net/policy.json unable to switch off protection you turned on. (#194)
  • Closed bypasses where rm -r without -f, a caffeinate-wrapped command, and some GNU parallel templates escaped the checks their equivalent forms get. (#191, #188, #190)
  • Every denial now carries a stable rule ID, so explain --json, the audit log, and checkCommand always identify which rule fired. (#193)

Added

  • Added CC_SAFETY_NET_PROJECT_TIGHTEN_ONLY=1. With it set, project policy settings that weaken the user policy — a lowered level, disabled capabilities, disabled protections, rules switched off, worktree relaxations, and added allow paths — are ignored, while the project file's tightenings still apply. status and doctor label the ignored deltas, and the statusline drops its weakening marker. The variable is listed in --help and doctor. (#194)
  • Added a ruleId to denials that previously reported none, including analysis and recursion limits, strict-mode parse failures, unsupported heredoc syntax, unverifiable dynamic shell sources, and working-directory denials. checkCommand now always returns ruleId on a deny result. (#193)
  • Added a doctor warning when a legacy inline rule config (.safety-net.json or ~/.cc-safety-net/config.json) still exists even though it is no longer loaded, naming the files and pointing to cc-safety-net rule migrate.

Changed

  • Changed find <subdir> -delete to be allowed when its starting point resolves inside the workspace, matching what rm -rf <subdir> already allowed. find . -delete, starting points outside the workspace, -L and -follow, and Git metadata in a repository stay blocked, as does any such find -delete while paranoid rm is on. (#192)
  • Changed the workspace scoping for find -delete to follow the effective rm.recursive-force-paranoid rule state, so an override of that rule now applies identically to rm -rf and find -delete.

Fixed

  • Fixed uninstalling the Kimi CLI hook writing an invalid TOML config when a commented-out hook preceded the managed entry. (#182)

Breaking Changes

  • Renamed the rule IDs reported for the pre-analysis guards: policy-protection is now guard.policy-config, policy-apply-protection is now guard.policy-apply, and git-metadata-protection is now guard.git-metadata. This affects anything that matches on ruleId from explain --json, the audit log, or the checkCommand library API. Denial reasons and behavior are unchanged.
    • Migration: Update any dashboard, filter, or script that matches the old IDs to the new guard.* names.

Security

  • Fixed rm -r, rm -R, and rm --recursive without -f skipping the target checks that the -rf forms get, so a recursive delete outside the current directory is now blocked, including through xargs and parallel. Strict and paranoid rm rules now apply to these forms as well. (#191)
  • Fixed caffeinate <command> not being unwrapped like nohup and timeout, which let the wrapped command skip device, interpreter, and custom-rule checks. (#188)
  • Fixed GNU parallel job values not being shell-quoted the way parallel itself quotes them, which let templates such as parallel {} ::: 'rm -rf /' and parallel 'sh -c {}' ::: 'rm -rf /' through. A quoted template with a very large job list also no longer exhausts the analysis budget, and such a template no longer picks up the linked-worktree relaxation. (#190)