Codapult Guard MCP Server

@codapult/guard

Architecture guardrails for AI coding agents

@codapult/guard is a local-first, model-agnostic architecture guard for JavaScript and TypeScript projects.

It learns what already exists, records the project’s architectural memory, and can protect future changes from introducing regressions covered by the project’s approved policy.

See the value in one change

Suppose a SaaS project has an established boundary:

Client → Server Action → Service → Repository → Database

An AI agent can still produce code that is valid TypeScript but crosses that boundary:

Client → Database

After the project has explicitly approved a matching import rule or deterministic contract, Guard checks the changed files and reports matching violations deterministically:

Codapult Guard (changed files)
Scanned 1 source file(s); suppressed 12 baseline finding(s).

src/app/settings/page.tsx:1 [client-no-persistence-import]
  Client modules should not import persistence-layer modules.
  import: @/lib/db/client

✗ 1 issue(s) found
Exit code: 1

The file path, rule ID, message, and counts depend on the project. This is the actual CLI output shape: Guard does not infer that every Client → Database edge is forbidden, and it does not activate proposals silently. The team approves the relevant policy first; then existing findings can be baselined while newly matching violations fail the gate and give the agent bounded evidence to repair.

Guard does not tell every project to use the same architecture. It discovers the architecture that is already there, then lets the team decide what becomes policy.

The core is universal. The strongest first-class scenarios are Next.js SaaS and AI-assisted development, including server/client boundaries, routes, persistence, authentication, billing, background jobs, environment configuration, and AI integrations.

Part of the Codapult ecosystem

Guard is an independent open-source project from Codapult. It does not require Codapult and can be installed in any JavaScript or TypeScript repository.

The relationship is complementary:

Use standalone Guard for any compatible project. Use the Codapult CLI when working on a Codapult SaaS project and you want project management, database, plugins, deployment, MCP, and Guard in one CLI.

        Existing project
              │
              ▼
       deterministic discovery
     AST · files · imports · Git
              │
              ▼
        project architecture
  capabilities · graph · impact paths
              │
              ▼
       approved project policy
  rules · contracts · conventions · baseline
              │
              ▼
          change verification
   check · review packet · verify · CI

Why Guard exists

AI agents can produce syntactically valid code that still violates the architecture of a real project: a client component imports server-only code, a new action bypasses the established auth boundary, a route writes to the database directly, or a change duplicates a service that already exists.

Existing tools remain essential, but they solve different problems:

Install

Requirements: Node.js >=20.19 and a JavaScript or TypeScript project.

pnpm add -D @codapult/guard
# or
npm install --save-dev @codapult/guard

The package exposes the codapult-guard binary:

pnpm exec codapult-guard init

The npm package is scoped as @codapult/guard; the executable intentionally remains codapult-guard for discoverability and consistency with the standalone product name.

60-second quick start

Run from the project root:

# 1. Build the initial project model and baseline
pnpm exec codapult-guard init

# 2. Inspect only new and changed architecture findings
pnpm exec codapult-guard check --changed

# 3. Prepare deterministic context for an AI review
pnpm exec codapult-guard review --requirement docs/acceptance.md

# 4. Run the configured completion gate
pnpm exec codapult-guard verify --json

init is protected and refuses to overwrite an existing baseline. Use init --force only when deliberately replacing the project memory. Use analyze to refresh discovered facts without resetting the baseline.

The operating model

Guard separates facts, policy, verification, and decision:

Guard does not assume a fixed UI → actions → services → repositories → database architecture. It can discover that shape when the project exhibits it, but observed patterns become enforceable only after explicit approval.

Policy paths are validated as project-relative paths. Guard rejects traversal, absolute paths, and symlinks escaping the project root; import-boundary checks include imports, re-exports, and literal dynamic imports.

Policy scope and state changes

Guard stores policy at the project level, while each policy item can target a narrower boundary:

Routine checks do not change source code, rules, contracts, baseline, or waivers. Commands that change policy are explicit: init, rules/contracts approve|reject, baseline accept|remove, and waiver add|renew|remove. analyze refreshes derived project facts, while verify may run the project's configured commands and records a local run manifest; neither changes approved policy.

What Guard discovers

The model is framework-aware without being framework-dependent:

Capabilities are evidence, not requirements. A Vite app, Express service, Hono project, Node package, monorepo, or Next.js SaaS can all use the same Guard core.

What Guard is — and is not

Guard is an architecture control plane for AI-assisted development. It protects project-specific boundaries and change impact using local facts, approved policy, and deterministic verification.

Guard is not a replacement for ESLint, TypeScript, tests, SAST, or a general-purpose PR bot. Those tools answer different questions; Guard connects their results with the architectural memory that an AI coding agent needs before and after changing a repository.

The normal loop

init once → edit → check --changed → review → verify → commit / merge
                         ↘ analyze after structural changes

1. init builds project memory and establishes the initial baseline.
2. check scans the current project; check --changed is the fast change-scoped architecture gate.
3. review prepares a bounded and redacted diff packet for an AI host; it does not call an LLM.
4. verify runs Guard policy, configured project checks, adapters, runtime diagnostics, and contract validation.
5. audit inspects the complete current state, including findings accepted by the baseline.

For a focused change explanation, use codapult-guard impact <file...> or the equivalent codapult_guard_impact MCP tool. It reports both directions of the dependency graph: what the changed module uses and which transitive callers may be affected. review includes the same impact packet plus typed Git changes (added, modified, deleted, and renamed) for the AI host.

Guard state is stored in .codapult/guard/:

.codapult/guard/
├── project.json       discovered project model
├── architecture.json  observed architecture and capabilities
├── conventions.json   recurring project conventions
├── rules.json         active and proposed deterministic rules
├── contracts.json     project-specific boundaries and required calls
├── proposals.json     evidence and approval history
├── baseline.json      accepted pre-existing findings
├── agent.json         AI-host completion-gate configuration
├── waivers.json       time-bounded exceptions to active findings
└── history/           project snapshots and local verification run manifests

Commit policy and baseline files when the team wants shared guardrails. Treat cache artifacts as disposable according to the project’s policy, and never commit secrets.

Baseline fingerprints do not include line numbers, so formatting and line movement do not recreate the same finding. They do include the rule and affected file/import identity, so a rename or module move can produce a new fingerprint and should be reviewed explicitly before accepting it into the baseline.

Temporary waivers

Baseline records legacy findings that existed when Guard was introduced. A waiver is different: it temporarily suppresses one active finding and must have an owner, reason, and expiry date.

codapult-guard waiver add <fingerprint> \
  --owner platform-team \
  --reason "Migration in progress" \
  --expires 2026-12-28
codapult-guard waiver list
codapult-guard waiver renew <id> --expires 2027-01-31 --reason "Migration continues"
codapult-guard waiver remove <id> --reason "Migration completed"

Guard warns when a waiver is within the configured warning window (14 days by default). Once it expires, the original finding is active again. Protected policy can forbid waiver changes through MCP so an agent can propose a waiver but cannot approve it itself. Waivers are intentionally fingerprint-specific; changing the violating code invalidates the waiver.

Teams can optionally cap each new waiver or renewal with waiverPolicy.maxDays in rules.json:

"waiverPolicy": { "warningDays": 14, "maxDays": 90 }

The cap applies to the requested grant from the current operation; it does not silently delete or rewrite existing waivers. Boundary findings with severity error fail check; warning findings and waiver-expiry reminders remain advisory.

Run codapult-guard doctor to detect an explicitly downgraded client or package boundary. Doctor reports it as a warning and leaves the project policy unchanged.

Optional scoped budgets

Budgets are policy, not a universal style rule. Add them only for a named risk boundary such as a service, route handler, or dependency-heavy module:

{
  "id": "service-lines",
  "description": "Services must remain reviewable.",
  "metric": "lines",
  "scope": ["src/services"],
  "limit": 300,
  "severity": "warning",
  "reason": "Keep service changes reviewable by one owner.",
  "status": "active"
}

Place budgets in the budgets array in .codapult/guard/rules.json. Supported metrics are lines, bytes, and imports. Generated files, schemas, migrations, and other paths are not checked unless they are explicitly included in scope; a wildcard such as * can intentionally cover the project root. Invalid, absolute, parent-directory, or nonexistent scopes fail the Guard gate. Changing a budget is a policy decision: review the diff and update its written reason rather than silently increasing the limit.

AI agents and MCP

Guard is deliberately model-agnostic. It does not send source code to a remote LLM and does not edit source files by itself. The AI host owns the model call, permissions, repair loop, and final decision.

Start the standalone MCP server over stdio:

pnpm exec codapult-guard mcp-server

Register that command in the MCP client from the project root. For example, Cursor can use .cursor/mcp.json:

{
  "mcpServers": {
    "codapult-guard": {
      "command": "pnpm",
      "args": ["exec", "codapult-guard", "mcp-server"],
      "cwd": "."
    }
  }
}

For clients that accept a generic stdio server, use the same command and set its working directory to the project root. Guard reads local files only; no API key or model provider is required. Host-specific examples are in docs/integrations/.

Recommended agent loop:

task finished
  → codapult_guard_next_action
  → codapult_guard_context
  → codapult_guard_review(requirement, diff)
  → codapult_guard_verify
  → repair reported failures
  → repeat until pass or bounded iteration limit

For Cursor, Claude Code, Codex, Gemini CLI, GitHub Copilot, and generic hosts, see docs/integrations/.

MCP Registry

Guard is published in the official MCP Registry under the server name io.github.codapult/guard. The Registry is the discovery layer for the published @codapult/guard npm package and its stdio MCP server; it does not replace npm installation or the host-specific configuration above. For deterministic setup, install the npm package directly and use the MCP configuration shown below.

For workflows where the authoring agent must not approve its own policy proposals, set Guard to protected mode in rules.json:

{
  "approval": {
    "mode": "protected",
    "allowMcpApproval": false,
    "requireDistinctActor": true
  }
}

MCP can then read and propose policy, while approval happens through the CLI or a protected CI/PR process. With requireDistinctActor, CLI and permitted MCP approvals require GUARD_APPROVER, and Guard rejects the same declared actor when a proposal was generated with GUARD_PROPOSER. These variables provide declared provenance only; external branch protection or signed identity remains responsible for proving who approved the change.

See the extension map for the supported AI-host, CI/PR, policy-pack, tool adapter, approval-governance, and observability integrations.

CI

Copy the consumer workflow into a project that has installed and initialized Guard:

cp node_modules/@codapult/guard/docs/guard-ci.yml .github/workflows/guard.yml

Or copy it from docs/guard-ci.yml. It runs project verification and exports Guard findings as SARIF for GitHub code scanning.

The package repository separately runs its own unit, typecheck, build, and packaging checks in .github/workflows/ci.yml, while the fixture workflow tests Guard on real project shapes.

CLI surface

Use analyze --refresh after a structural change. doctor --fix-cache removes only the disposable discovery cache; it does not change rules, contracts, baseline, or source files.

Guard state is safe for concurrent CLI/MCP readers and writers: derived facts are published as an atomic generation, policy updates use revisions, and short write contention is waited out. A process that dies while holding the state lock is detected by its local PID and the lock is recovered; use --no-wait when an integration needs immediate contention feedback.

Run pnpm exec codapult-guard <command> --help for command-specific options.

Every verify run also writes a local manifest under .codapult/guard/history/runs/<run-id>.json. It records stage durations, the outcome, and the policy gate that decided the result. It contains no source code or external telemetry. These manifests make a failed run explainable without turning Guard into a production tracing system.

Security and data handling

• Deterministic discovery and checks run locally.
• Review packets are bounded and redact common secrets before they are returned to an AI host.
• Guard does not invoke an LLM or require a provider API key.
• Project commands and external adapters run only when enabled by the project configuration.
• Existing findings can be baselined, but new regressions remain visible.

Verification and proof

The repository validates the product through multiple layers:

• unit and integration tests for discovery, policy, baseline, verification, MCP, and output;
• AST adversarial cases for aliases, re-exports, dynamic imports, and route boundaries;
• golden end-to-end flow from violation to repair;
• mutation regression checks across real Next.js, React/Vite, Node, Hono, monorepo, and Express repositories;
• npm pack checks to ensure the published artifact contains only the intended build output.

Run the maintainer checks locally:

pnpm test
pnpm test:guard:golden
pnpm test:guard:fixtures
pnpm test:guard:fixtures:regression
pnpm release:check

Documentation

• Complete Guard guide
• AI-agent integration
• Host integrations
• CI consumer workflow
• Fixture matrix
• Release process

Project status

@codapult/guard starts at 0.1.0 as a public alpha. The deterministic core is usable, tested, and intended for real projects, while policy schema and integration surfaces may still evolve before 1.0.0.

License

MIT. See LICENSE.