Two pipelines, one workspace, one place to look.

1. The summary comment

Every push that opens or updates an MR triggers the products you have enabled for that repo. When each finishes, the bot drops a single comment with the verdict, the top findings/remarks, and a link to the full report. Re-reviews update the existing comment in place — they never spam the discussion tab.

If both products run on the same MR, you get two summary comments — one per pipeline — so you can read «security said this, review said that» at a glance instead of disentangling them by hand.

2. Inline notes on the diff

Security scans — critical and high-severity findings get an inline note anchored to the exact line. When the AI is confident in the fix, the note carries a native suggestion block: one click in GitLab and the change is committed.

Code review — every remark is its own discussion thread on the changed line. No top-level wall of text, no "scroll to find what I'm being asked about". Each thread carries a "Suppress" chip; click it once and CodeGuards posts the closing reply and resolves the thread in GitLab.

3. The buttons in the comment

• Suppress — silences this finding/remark on this repo. Use it when the bot is wrong; we won't bother you with the same one again. Per-repo, per-fingerprint, with a category-path fallback so a rephrased AI output still hits the same rule.
• Apply suggested fix (Security scans only) — pushes the AI's patch to a side-branch codeguard/fix/.... Open a follow-up MR if you want to ship it.
• Open full report — the per-run dashboard with timeline, AI cost, suppression history, and (for review) the rulebook that fired.

Repository memory improves over time

Accepted suppressions remain scoped to that repository. Architecture expectations accumulate in the rulebook and in what the team has already accepted. Historical decisions persist in the audit trail — who marked what, when, and why.

Repository context reduces repeated discussions: the same "we do this here because…" explanation is recorded once, not rehashed on every merge request.

4. Talking back to the reviewer

Reply in any CodeGuards thread with a question and the reviewer reads the surrounding diff plus the original finding/remark and writes a focused answer. Slash commands work too:

• /codeguards suppress — same as the button. Works for both scan findings and review remarks.
• /codeguards fix — same as Apply suggested fix.
• /codeguards explain — make the bot expand the recommendation in plain English.
• /codeguards help — list every command.

Each thread has a cap on how many AI replies we'll send so we never get into a "are you sure?" loop with an impatient reviewer.

5. Tuning the bot per repo

Open Integrations, find your repo, and tune each product independently:

• Security scans — review style (chill / balanced / strict), minimum severity floor, tone (professional / friendly / blunt).
• Code review — per-repo rulebook controlling which categories are loud (style, naming, tests, error handling, architecture-boundary bypasses) and which are silenced. Defaults match the language/framework we detect.
• Per-repo enablement — toggle each product per repository. Run scans on the public-facing API repo, reviews on the design system, both on your monolith.

Changes apply to the next run — no redeploy, no migration, no run to re-trigger by hand.

6. Architecture boundaries the bot remembers

The Code review pipeline holds a per-repo rulebook that includes your team's architecture decisions — bounded contexts, layered dependencies, "the controller never talks to the model directly" rules. When a diff bypasses one, the reviewer flags it as a remark on the offending line, with a one-line citation of the rule. Suppress once if the bypass is intentional; the team's actual policy stays in version-controlled config, not in a Confluence page nobody reads.

7. Connection modes

Choose the setup that matches how much repository access your security team is comfortable delegating to CodeGuards. You can start with the fastest managed setup, or keep GitLab credentials entirely inside your infrastructure.

• Full SaaS integration — paste a GitLab/GitHub token once. CodeGuards stores the token, registers webhooks, posts inline comments, resolves stale GitLab threads, and powers slash commands. This is the fastest setup and the richest UX.
• CI runner only — keep GitLab credentials in your pipeline. The job sends CodeGuards the MR diff, changed files, metadata, and requested products via POST /ci/reviews and POST /ci/scans. GitLab tokens are used only inside CI to publish comments.
• CI runner + realtime relay — add a tiny customer-hosted Docker service for GitLab comment webhooks. The relay keeps the GitLab token locally, sends only discussion text/finding context to POST /ci/thread-replies, then posts the answer back to GitLab.
• Customer-hosted compute instance — run one long-lived Docker worker in your network. It receives GitLab MR and Note webhooks, fetches diffs with your local GitLab token, sends review/security bundles to CodeGuards Cloud, and publishes comments back to GitLab. CodeGuards Cloud never stores SCM credentials.

The local modes are designed for teams that do not want CodeGuards SaaS to hold repository credentials. The trade-off is setup effort: CI variables, a repository connection id, and optionally a stable tunnel or internal host for realtime replies. The compute instance is the cleanest privacy-first option when a security team wants a single self-hosted access plane. Read the self-hosted setup guide.

8. Zero-config setup

Connect GitLab (cloud or self-hosted) or GitHub once on the Integrations page. CodeGuards registers the webhook for you, seeds a baseline ruleset for your stack on both products, and starts reviewing the very next push. There is nothing to add to .gitlab-ci.yml or .github/workflows in the managed mode — both pipelines are event-driven. CI mode (POST /ci/scans, POST /ci/reviews) is available when you want the pipeline to own repository access.

FAQ

Will it spam my MR?

No. One summary comment per product per review, plus inline notes per anchored finding/remark. Re-runs update the existing notes in place. Soft caps prevent runaway threads.

Does it ever push code to my MR branch?

Never. Auto-applied fixes always go to a fresh codeguard/fix/... branch — you decide whether to merge them.

Can I run only one product on a repo?

Yes. Per-repo toggle. You can also start with Security scans on every repo and roll out Code review gradually as you tune the rulebook.

GitLab + GitHub?

Both. GitLab cloud and self-hosted; GitHub cloud. Same product surface on both — inline comments, summary verdict, suppression buttons. The one capability gap: only GitLab supports auto-resolving threads (GitHub's REST API doesn't expose it).