Skip to main content
cc-safety-net gui opens a local dashboard. Use it to review decisions on this machine and edit your policy without editing JSON by hand. The dashboard helps you find what was blocked, why it was blocked, and what you can change. This page covers what you can do in the dashboard and which actions are destructive. It does not restate the underlying formats: the policy.json schema lives in Policy, rulebook authoring in Custom rules, and the audit record schema in Audit log.

​
Launch the dashboard

The command prints the dashboard URL and then opens it in your default browser:
Pass --no-open when you want the URL without a browser launch, for example over SSH, in a container, or when you would rather paste the URL into a specific browser profile:
--no-open is the only flag besides -h, --help. Any other argument is rejected with Usage: cc-safety-net gui [--no-open] and a non-zero exit code. If the browser cannot be launched, the command prints the underlying error followed by Open this URL manually: <url> and keeps serving. The server runs in the foreground until you stop it with Ctrl-C.

​
Local loopback scope

The dashboard is not a hosted service. Its server listens only on the local loopback interface:
  • The server binds to 127.0.0.1 only, on an ephemeral port. Nothing on your LAN can reach it.
  • Each launch mints a fresh random token that is embedded in the URL. Every request must carry that token, and every state-changing request must also send it as a request header. Requests without it are rejected with 403.
  • A JSON request body larger than 1 MiB is rejected with 413 and the error Request body is too large before it is parsed, because the whole body would otherwise sit in memory.
  • Responses are served with cache-control: no-store.
The token is printed on stdout, so whoever launched the command can read it. That is what lets the browser page work at all, and it means an agent that ran cc-safety-net gui itself can reach the same token-gated endpoints, including the project-policy apply described below. The token keeps out another page, and any process that never saw that line. It does not keep out the launcher. What stays closed is the direct route: an agent editing policy.json by command, or running cc-safety-net policy apply, is still denied. The page makes no outbound requests for its data. Everything it renders comes from your local policy file and audit logs. The update check and GitHub star action on Overview are the only opt-in exceptions.
Because the token is per-launch, a URL you bookmarked from a previous session will not work. Run cc-safety-net gui again to get a fresh one.

​
The six views

The sidebar has six views, hash-routed so you can link or bookmark within a session: An unrecognized hash falls back to Overview. Integrations and Rules load their data the first time you visit them.

​
Overview

Overview summarizes a retained window, not a lifetime total. The window is the last 7 days, or your entire retention window when retention is shorter than 7 days. The heading states the window it used, as Last N day(s). Tiles. The Blocked and Analyzed counters each have a per-day sparkline that runs from oldest to newest. Each sparkline scales to its own maximum, so compare the numbers rather than the bar heights. Protection status. A card names your safety level, adds · Customized when your overrides deviate from the preset, and reports how many rules are active and whether secret protection is on. This card reflects saved state only. Unsaved toggles on the Policy view do not change it until you save. A banner appears when destructive-command protection or secret protection is off, or when a configuration error causes the runtime to enforce a fallback. Health strip. Reports whether the hook is active in your detected agents, or that agents were detected without an active hook, or that no agent hooks were detected at all. It also surfaces an available update. When something needs attention it links to Integrations. Top blocked commands and Top blocked rules. Two top-five ranked panels, counted across the same window as the tiles. Selecting a top command jumps to Activity with an exact, blocked-only command-signature filter applied as a removable pill. Selecting a top rule routes by rule namespace: custom.* rule ids go to the Rules view, and built-in rule ids go to Activity with the rule id prefilled in the search box. Guard errors. When any denial in the window came from a failed evaluation rather than from policy, a button appears with this text: Selecting it opens Activity filtered to error decisions. These are fail-closed denials: CC Safety Net could not finish the analysis, so it refused the command. See Troubleshooting if they recur.

​
Activity

Activity lists audited commands from the local log, newest first. Secret redaction runs before each write, but it recognizes only known credential shapes. Entries can still contain paths, hostnames, and names. See Audit log for the record schema and redaction scope before sharing anything from this view.

​
Windows are derived from retention

The window selector is not a fixed set of choices. It is computed from your configured audit retention: the candidate windows 7, 30, 90, 180, and 365 days are filtered to those strictly shorter than your retention. Your retention value itself is always appended as the widest option. That way no option ever promises history the retention sweep has already deleted, and your whole log always stays reachable. Windows use whole local calendar days, including today and the preceding days. The per-day sparkline buckets on Overview therefore sum to the totals. A request for a window wider than retention is rejected. If you shorten retention, the dashboard clamps the current selection to the new limit. See Audit log for how retention is configured and enforced.

​
Filters

  • Window. The retention-derived selector described above.
  • Decision chips. All, Blocked, and Allowed always appear. Errors appears only when the window contains guard errors, and Likely false positive appears only when the heuristic finds candidates. The heuristic flags a denial that carries a failure stage or a command signature denied two or more times in the same session.
  • Agent chips. These appear only when the window contains two or more known agents. Use All agents to clear the filter.
  • Command pill. This exact, blocked-only command-signature filter appears after you select a command on Overview. You can remove it here.
  • Search. The top-bar box (Filter by rule or command) matches rule ids and command text as a case-insensitive substring.
Filters that no longer make sense self-heal on reload. If the agent you filtered on is gone, or the window has no errors or no false-positive suspects, the filter resets rather than showing an empty feed.

​
Refresh

The refresh button reloads both Overview and Activity, so the tiles and the feed never disagree. It holds a short minimum spin so a fast local refresh still registers as an action.

​
Rendered entries versus counts

The feed renders at most 500 entries. Each decision class receives half the cap and lends its unused share to the other. A burst of denials therefore cannot remove all allowed entries from the view. The counts are not capped by the 500-entry limit. Chips, tiles, and the top panels are computed from full-window aggregates on the server, independent of what the feed renders. The footer states both, as Showing X of Y entries from the last N day(s), adding (capped at 500, newest of each decision) when truncation occurred. There is one case where the counts themselves fall short: when some audit log sources could not be read, the footer appends N audit log source(s) could not be read, so this list is incomplete. The aggregates miss those entries too, so treat both the list and the counts as a floor rather than a total until the sources are readable again.
Read the footer before drawing conclusions from a scan of the list. Showing 500 of 4,120 means the list is a recent slice while every chip and tile still reflects all 4,120 entries.

​
Per-entry actions

Each entry carries a decision badge (Blocked, Allowed, or Error), an agent badge, a rule-id chip, a relative timestamp, and a button to copy the raw log entry as JSON. Long commands are clamped with a Show more toggle. The copied entry is the raw audit record. See Audit log for its fields. Denied entries offer Report false positive, which opens a dialog that prepares a prefilled public GitHub issue. You can edit the command and log entry before you continue. The dialog replaces your project path with <project> and your home directory with ~. Nothing is submitted until you submit it on GitHub. Allowed entries offer Block this in future, which prefills the prompt composer on the Rules view with that command. It does not create a rule on its own. See Rules below.

​
Policy

Policy is where you choose what CC Safety Net blocks. Everything on this view is a built-in protection: the safety preset, the destructive-command rules, and the secret-protection patterns that ship with CC Safety Net. Your own rulebooks are a separate mechanism and are not edited here. The full field-by-field contract for the file this view writes lives in Policy.

​
Saved versus unsaved

Edits accumulate in a draft and apply only when you save.
  • A save bar appears on the Policy view whenever the draft differs from what is on disk, with Discard and Save.
  • An Unsaved policy changes · Review chip appears in the top bar on every other view and jumps here when clicked.
  • The draft survives a reload within the browser session. Saving, discarding, repairing, or resetting clears it.
  • Leaving the page with unsaved changes prompts you first.
Saving writes the policy file and reports its path. While the on-disk policy has an error, every form control shows the built-in default instead of the values that the runtime salvaged from disk. Only the raw JSON mirror shows the file’s contents. The dashboard refuses to save in this state with Repair policy before saving changes. This prevents the displayed defaults from overwriting your file. Repair the policy before saving. The form then reloads the settings that the repair preserved.

​
Draft a project policy

Draft project policy in the view head switches the whole Policy view into a draft of the project file. The draft bar names the path it writes and states the rule that file follows: Only the fields you mark are written here; everything else keeps inheriting from each member's own policy. Exit draft returns you to editing your own policy. Change… retargets the draft at another directory when a native directory picker is available, and discards the current draft when you accept the confirmation. Until you change it, the target is the directory the dashboard was launched from. Marked versus inherited. Every control gains a chip naming whose value it is showing. Inherited means the field stays out of the project file and each member keeps their own value. Set by project means the draft writes it, and clicking that chip drops the field back to inherited. Editing a control marks its field. A marked path list shows the project’s own entries only, so marking one starts it empty rather than publishing your personal paths into the repository. Review and apply. Save becomes Review & apply. It asks the server for the diff and opens an Apply this project policy? dialog carrying the target path and a Setting / Now / After table of the effective policy before and after, with (unset) where a field is absent from one side. No change to the effective policy. replaces the table when nothing differs. Below the table the dialog lists one warning per field the draft relaxes relative to your user policy, in the same wording Policy documents, and adds The existing project policy file is invalid and will be replaced. when the file already on disk cannot be read. Cancel is focused by default. An edit that lands while the diff is loading forces another pass, with Error: the draft changed while the review was loading. Review it again. If a second tab moved the project directory, the draft reloads for the new target and asks you to review it again before applying. When the draft refuses to start. A user policy with errors degrades to protective defaults in the runtime, and a draft seeded from those would present defaults as the baseline your team inherits. So the dashboard refuses, reporting Error: repair your user policy before drafting a project policy. with the diagnostics. A project file that exists but cannot be read behaves differently. The draft starts empty and prints that file’s diagnostics above the form. The same guarantees as the CLI. The draft is cc-safety-net policy check and cc-safety-net policy apply behind a form. It writes the same sparse file, diffs the proposal against the same runtime user baseline, and writes nothing until you confirm. See Policy for the file contract and the rules by which the two scopes merge. One difference is worth knowing. cc-safety-net policy apply run by an agent is hard-stopped by the guard, because rewriting the configuration CC Safety Net enforces has to come from you. The dashboard apply is that same human action. You click it on a page only someone holding the session token can open, and as Local loopback scope notes, an agent that launched the dashboard holds that token too.

​
Test a command

Paste a shell command into Test a command to see whether it would be blocked. The test evaluates against your current unsaved edits, so you can check a change before committing to it. In a project draft the test evaluates what the runtime would load, which is the inherited baseline with the draft’s marked fields laid over it. It takes each path list as the union of your own entries and the draft’s, because the loader unions them. The same evaluation feeds the protection summary and the per-rule status lines on this view, so a marked path list that reads empty on screen does not make your own paths look unprotected. The test also enforces custom rulebook rules loaded from disk, although the dashboard cannot edit rulebooks. Treat it as a preview of the full decision, not only the built-in layer. Use explain for the same analysis in the terminal.

​
Safety preset

The view offers three safety presets: Standard, Strict, and Paranoid. Each preset supplies inherited defaults that you can customize for the workspace. Modes defines what each preset and capability changes. The view reports environment variables that raise protection. This notice explains why behavior can be stricter than the displayed level. The Advanced overrides section is collapsed by default. It exposes fail closed, paranoid rm -rf checks, and paranoid interpreters, so you can change one capability without changing the preset. Configure workflow exceptions separately from the safety level.

​
Destructive command protection

A master switch, then the rules grouped into four collapsible tiers: Every tier starts collapsed. A Policy search opens each tier with a match. The Always enforced tier has no switch or per-rule checkboxes. Its header counts the rules as N protections, and each rule is marked Always enforced with a ? example popover. The three configurable tiers show N on · N off counts next to a tier switch labelled All <tier> protections. The switch is checked while at least one rule in the tier is on and disabled while the master switch is off. Flipping it writes the same per-rule overrides as the individual checkboxes. A rule that matches its inherited value keeps no override, so there is no separate stored group setting. While the master switch is on, the panel summary reads N active, N disabled. Turning it off replaces that text with Configurable protection disabled. Catastrophic protections remain active; saved rule settings and allow paths are preserved. The Always enforced tier keeps blocking. Each configurable rule card has a ? popover with a command it blocks. A status line identifies the source of its current value. For example, means the master switch takes precedence over your override. Toggling a rule stores an explicit on or off override. Setting a rule back to its inherited value deletes the override rather than storing a redundant one, and each rule offers Use inherited setting to do that directly. A Restore defaults action in the panel head clears every override at once. Allow paths live in this panel. Recursive deletes targeting a listed path are not blocked, which is what makes /tmp workable. Entries must be absolute or ~/-prefixed directories, and your home directory is rejected. See Allow paths for the full validation table and Allowed commands for what an allow path does and does not relax.

​
Secret protection

This panel has a master switch and per-pattern checkboxes grouped by category. Categories include default sensitive paths, Coding CLI credential locations, and Coding CLI config locations. Each group header is a collapse button that shows N on · N off next to a switch labelled All <category> protections. The switch is checked while any rule in the group is on, disabled while the master switch is off, and writes per-rule overrides in bulk. Groups start collapsed and open during a Policy search. Rules that protect literal file paths carry a ? button opening a Protected paths popover that lists exactly which paths the rule covers. Not every rule defaults to on. Coding CLI config rules ship off because settings and MCP configuration files can contain credentials, but agents edit them as routine work. You must enable these rules individually. A checkbox stores an override only when it differs from the default. Checking a default-off rule writes an on override, and unchecking it removes the override. For a default-on rule, unchecking writes off and rechecking removes the override. While the master switch is on, the panel summary reads N active, N disabled. When it is off, it reads Protection disabled. Saved rule settings and deny paths are preserved. Saved secret allow paths are also preserved in the draft. Deny paths live in this panel. Configured paths and everything inside them are blocked while secret protection is on. Turning secret protection off also stops enforcing deny paths. See Deny paths for the accepted entry forms. Allow paths also live in this panel. An exact file or directory tree can be exempted from the built-in pattern rules, but deny paths and Coding CLI protections still apply. The dashboard validates each addition before it enters the draft. Glob patterns, paths that cover home, and the guard’s own configuration are rejected. See Secret allow paths for the complete precedence and validation rules.

​
Policy JSON

The Policy JSON panel sits at the bottom of this view. It is a read-only mirror with a copy button, not a second editor. Its subtitle names what you are looking at:

​
Actions that ask for confirmation

Individual rule toggles, preset changes, and adding or removing paths are staged in the draft and gated by Save, so they are not separately confirmed. The dashboard reserves modal confirmation for actions that reduce protection or discard configuration: Cancel is focused by default in every one of these dialogs.
Turning off destructive command protection or secret protection disables every configurable rule in that layer until you turn it back on. Only the Always enforced destructive tier keeps blocking. Prefer a single rule override or a lower preset over the master switch.

​
Repair

When the policy file on disk has errors, a Policy repair available banner appears on this view with a Repair button. Repair writes canonical JSON, preserving every valid setting and discarding invalid fields. If the JSON cannot be parsed at all, defaults are restored instead. The button is inert when the loaded policy has no errors.
Repair discards invalid fields, and falls back to defaults when the file cannot be parsed. If the file contains hand-written configuration you care about, copy it somewhere safe before repairing.

​
Reset

Reset is deliberately not on this view. It lives in Settings, under Danger zone.

​
Rules

Rules covers custom rulebooks that you author. These are separate from the built-in protections on the Policy view. See Custom rules for the rulebook format, scopes, overrides, and validation.
The Rules view is not a rulebook editor. CC Safety Net never writes a rulebook from the dashboard. This view shows rules read-only as they are actually enforced, and composes prompt text for you to copy into a coding agent that does the authoring.

​
Rulebooks panel (read-only)

Each rulebook card shows its name, a version badge, its source spec when that differs from the name, its scope (All projects or This project), and its rule count. Rules are listed as enforced, after overrides. A rule disabled by an override still belongs to its rulebook and stays in the rulebook’s listing, but the rendered rule list omits it. This view therefore shows the effective rulebook, not the file contents. A refresh button reads the files again. When no rulebooks are configured, the panel points you at cc-safety-net rule init. When rulebooks exist but every one was dropped, it says so and sends you to Diagnostics.

​
Diagnostics

The Diagnostics panel is hidden when there is nothing to report. When it appears, an error there means a rulebook was dropped and its rules are not enforced. This is the place to look when a rule you wrote is not firing.

​
Prompt composer (copy only)

The composer builds a prompt for your coding agent. Its only action is Copy prompt. The view has no create, save, or write control, and no server route writes a rulebook. Inputs:
  • Scope. Project or All projects.
  • Project path. Shown only in project scope and prefilled with the directory where the dashboard was launched. When a native directory picker is available, the field is read-only with a Choose… button. If the picker is unavailable, the field becomes editable.
  • Request. Describe the rules you want. Rules match a command, its subcommand path, and exact arguments. They do not match file paths or patterns.
  • Examples. One-click starters for suggesting rules, blocking a command, and verifying existing rules.
The generated prompt tells your agent to use the cc-safety-net skill, and to run npx -y cc-safety-net rule doc first when that skill is unavailable and treat its output as the source of truth for schema, paths, and validation. It includes the scope, project path, and existing rulebook names so the agent can select an unused name. The text includes only rulebook names. It does not include rule names, blocked arguments, reasons, or versions. Copying is refused, with a specific message, when rules have not loaded yet, when the request is empty, or when project scope is selected with no project path.

​
Integrations

Integrations installs or removes the CC Safety Net hook for each coding agent on this machine. The Agents panel lists the detected CLIs and their hook status; see Integration architecture for how each agent is wired and Installation for the equivalent steps outside the GUI. Not inspected carries a tooltip spelling this out: This runtime's state file could not be read, so its status is unknown. The CLI itself was found, so installing is still offered. Detection gates the actions: when a CLI is not detected, no button is offered at all, because there is nothing to install a hook into. Install and uninstall are serialized, so two actions cannot interleave, and the button is disabled while its request is in flight. Failures report Install failed or Uninstall failed rather than silently reverting. The refresh button re-detects every agent, which is what you want after installing a CLI or editing an agent config by hand. A System panel below reports the CC Safety Net version, the Node.js version, and the platform detected on this machine.

​
Settings

Settings covers appearance, file locations, and maintenance. Appearance. A theme control cycling Auto → Light → Dark. The preference is stored in this browser, not in your policy. Files. Read-only rows showing where CC Safety Net reads and writes on this machine: the policy file and the audit log directory. A Project policy row appears between them when a project policy is in force, and a notice under the rows lists what that file changes, headed Merged on top of this file:. Audit log retention. Sets how many days of audit records to keep. See Audit log for the accepted range, recorded data, and sweep behavior. Unlike the Policy view, retention saves immediately on change with no save bar. You cannot save it while the Policy view has unsaved changes, and retention is user scope only, so you cannot save it while a project draft is open either. Unlike the Policy save button, this control remains active while the on-disk policy has errors. In that state, the form holds defaults, so changing retention writes an all-defaults document with only your new retention over the file. Repair the policy before changing retention.
Shortening retention is irreversible. The next sweep deletes audit entries older than the new window, and the Activity view can then look back only as far as the new value. The dashboard asks you to confirm and names the log directory it will prune. Export needed entries first. Each Activity entry has a copy-as-JSON button.
Version. A single read-only row showing the CC Safety Net version you are running. Danger zone. A single action, Reset policy, which restores the default policy JSON at the configured path.
Reset discards your saved configuration. Every preset choice, rule override, allow path, and deny path returns to defaults, with no undo. Reset affects only the policy file. It does not touch custom rulebooks.
For the policy file schema see Policy; for rulebook authoring see Custom rules; for the audit log format and retention behavior see Audit log; and for gui and every other command see CLI commands.
Last modified on August 31, 2026