Pin and Verify a Repository

Part of Guard. Start here to configure the product.

In the app, Guard opens on its Setup tab until a repo pushes: five steps covering the CLI, the first baseline, the first push, the CI check and what arrived, each with a prompt for your agent or the commands to run yourself. After the first push, Overview opens first and Setup moves to the last tab, ready for the next repo.

Check a Repo

Run these from the repo’s root with the cedr command line tool:

• cedr lint finds problems in the agent setup: broken commands and links in instruction files, malformed skills, hidden characters, servers not pinned to a version, broad permissions and risky patterns in skills.
• cedr lock pins every skill and server in .cedr/guard.lock and saves what each server offers in .cedr/surfaces/. Commit both.
• cedr verify compares the repo with the lock without going online, and fails when a skill, a server or how it starts has changed.
• cedr outdated checks each pinned npm server for a newer version and shows what that version would change: tools added or removed, descriptions or input schemas rewritten, new hosts it calls, new capabilities such as running programs or writing files. It reads the registry and never installs or runs anything. --fail-on high fails when a newer version adds a host or capability.
• cedr push sends the pinned skills and servers and the current findings to the Guard page in the app; --updates adds what cedr outdated found.

A repo locked by an earlier release has its lock at cedr.lock; the next cedr lock moves it into .cedr/.

First Baseline and Later Changes

Review drift before accepting a new baseline

1. InspectLint the current setup; verify an existing lock
2. →ReviewDecide whether each detected change is intended
3. →PinRegenerate the lock only after approval
4. →VerifyCheck and commit the reviewed baseline

For the first baseline there is no existing lock to verify. On later changes, locking first would accept the drift before you reviewed it.

1. Install the CLI and inspect the repository’s existing agent configuration.
2. Run cedr lint and review the findings. Fix mistakes before accepting the baseline.
3. Run cedr lock, inspect .cedr/guard.lock and .cedr/surfaces/, then run cedr verify.
4. Commit the reviewed lock and surface files with the configuration they describe.

For later changes, run cedr verify before regenerating the lock. A failed verification is the signal to review what changed. Run cedr lock again only after accepting the new skills, server versions or launch configuration; otherwise you would simply bless the drift.

Locking and checking use static inspection by default. Do not run an untrusted MCP server to test whether it is safe. A clean lint or verification result is not a security certification.

The Ask your agent menu at the top right of the Guard page in the app has Fix Guard findings (works through the findings of the repo that needs it most) and Review server updates (checks newer versions of pinned servers and explains what changed), beside Pin this repo and Add Guard to CI. Each copies a prompt filled in with your organization’s settings; see Ask Your Agent in the App.

Remove Guard

Removing Guard from a repository covers its lock, surfaces and settings in .cedr/, and its check in .github/workflows/cedr.yml, which also runs Sync’s check. Sync’s files stay. The repo stays on the Guard page until an owner or admin removes it there. In the app, Ask your agent has Remove Guard from this repo:

Remove Cedr Guard from the git repository I have open.

Before deleting anything, list every file, setting, registration and scheduled job you would remove, with its path, and wait for my approval on each one. Skip anything I want to keep. Back up every configuration file you will change or delete into a new folder ~/cedr-backup-<YYYY-MM-DD>/ first, keeping its path. Never touch my organization's data in the cedr.dev app. Finish by telling me what you removed, where the backups are and what is left.

1. List what Guard added: .cedr/guard.lock, .cedr/surfaces/, .cedr/guard.toml if present, and a legacy cedr.lock at the repo root if present.

2. Look at .github/workflows/cedr.yml. It runs Guard and Sync checks together. If the repo also has .cedr/sync.toml (Sync), keep the workflow and set verify: 'false' under with so only Guard stops; otherwise offer to delete the workflow.

3. Remove what I approve, and leave the rest of .cedr/ alone (Sync keeps its files there).

4. Commit the removal on a new branch with chore: remove cedr guard. Do not push unless I ask.

By hand: delete .cedr/guard.lock, .cedr/surfaces/, .cedr/guard.toml and any root cedr.lock; in .github/workflows/cedr.yml set verify: 'false' if Sync still uses it, otherwise delete the workflow; then commit. Remove the repo from the Guard page (Repos tab) to drop its record from the app.

Next, add Guard Checks in CI or report the baseline to the app.