From One AI Tool to Six: How theGuard Adapts to Any Coding Agent
When I first built theGuard, it only worked with one AI coding tool. The hooks were hardcoded, the configuration was specific to that tool's file format, and the integration points assumed a particular lifecycle. Then someone asked me if it worked with Cursor. Then someone else asked about Cline. Then Windsurf. Then Copilot.
I had two choices: copy-paste the integration code for each tool and maintain six parallel implementations, or build an abstraction that lets one set of safety logic work across all of them.
I chose the adapter pattern.
The Adapter Pattern
The core idea is simple. theGuard defines an interface called ToolAdapter with a fixed set of methods: initialize, installHooks, removeHooks, detectPresence, and getToolInfo. Each AI tool gets its own class that implements this interface. The safety logic, rule engine, and MCP proxy know nothing about specific tools. They work entirely through the adapter interface.
This means the rule engine does not care whether a tool call came from Cursor, Copilot, Cline, Windsurf, VS Code, or any other tool. It receives a normalized representation of the action, evaluates it against the rules, and returns a decision. The adapter handles translating between the tool's native format and theGuard's internal representation.
How Each Tool Handles Hooks Differently
The real complexity is in the adapters themselves, because every AI tool has a different mechanism for intercepting actions.
Cursor uses a hooks system defined in .cursor/hooks.json. You specify hook types (PreToolUse, PostToolUse, beforeShellExecution) and point them at executable scripts. When Cursor is about to call a tool or run a shell command, it executes your hook script and checks the exit code. Exit code 0 means proceed. Exit code 2 means block the action.
Cline uses a rules file (.clinerules) that can reference external validation scripts. The integration point is different, but the concept is the same: intercept before execution, check against policy, allow or deny.
VS Code extensions have their own lifecycle. theGuard's VS Code extension registers event handlers for terminal creation, file modification, and task execution. The extension calls the same rule engine but through VS Code's extension API instead of shell scripts.
Copilot integrates through its content exclusion and instruction files. The approach is less about real-time interception and more about constraining what the agent can access and do.
Windsurf and other tools each have their own conventions. Some support hooks natively. Others require creative workarounds. The adapter pattern absorbs all of this complexity so the rest of theGuard does not have to care.
Auto-Detection During Init
When you run theGuard's init command, it needs to figure out which AI tools are present in your project. The auto-detection system scans for telltale directory and file patterns.
It looks for .cursor/ (Cursor), .vscode/ (VS Code), .clinerules (Cline), .windsurf/ (Windsurf), and similar markers. It also checks running processes and installed extensions. The result is a list of detected tools, each paired with its adapter.
For each detected tool, theGuard generates the appropriate configuration files. For Cursor, it writes .cursor/hooks.json with hook definitions pointing to theGuard's executable scripts. For Cline, it updates .clinerules with the necessary references. For VS Code, it recommends installing the theGuard extension.
The generated configuration is non-destructive. If the tool already has configuration (maybe you have existing Cursor hooks for other purposes), theGuard merges its hooks into the existing file rather than overwriting. This was a deliberate choice, because safety tooling that breaks your existing setup will get uninstalled immediately.
Config Generation Per Tool
Each adapter knows how to generate its tool's configuration format. The Cursor adapter produces JSON. The Cline adapter produces a rules file. The VS Code adapter produces extension settings. But all of them reference the same underlying theGuard installation and rule set.
The generated hook scripts are minimal. They call theGuard's CLI with the relevant context (tool name, arguments, working directory), theGuard evaluates the action, and the script exits with the appropriate code. The scripts themselves are typically five to ten lines. All the logic lives in theGuard's core, not in the generated scripts.
This means upgrading theGuard's rule engine automatically improves protection across all tools. You do not need to regenerate configuration files when rules change. The configuration files point to the theGuard binary, which loads the latest rules at runtime.
The Shell Pre-Exec Hook
Beyond tool-specific adapters, theGuard installs a shell pre-exec hook as a universal safety net. This hook runs before every command in your terminal, regardless of which AI tool (or human) initiated it.
The pre-exec hook is lightweight by design. It checks the command against a fast-path filter first: common safe commands (ls, cd, cat, echo) are allowed instantly without hitting the rule engine. Only commands that match potential risk patterns (anything involving rm, docker, kubectl, terraform, aws, git push) get the full rule evaluation.
This two-tier approach keeps the hook's overhead imperceptible for normal terminal use while catching dangerous commands regardless of their origin. If an AI tool bypasses its own hook system and shells out directly, the pre-exec hook catches it.
The VS Code Extension
The VS Code extension exists because some integration points cannot be covered by shell hooks alone. VS Code extensions can intercept file saves, terminal creation, debug sessions, and task execution at a level that external scripts cannot reach.
The extension is thin. It registers event handlers, forwards relevant events to theGuard's core for evaluation, and displays notifications when actions are blocked. The actual decision-making happens in the same rule engine that powers every other adapter.
Having both the extension and shell hooks active creates defense in depth. If a VS Code action bypasses the extension (unlikely but possible), the shell hook catches the resulting command. If a command bypasses the shell hook (also unlikely), the extension may have already caught the VS Code action that triggered it.
The Vision
The adapter pattern was built with an assumption: new AI coding tools will keep appearing. Six months ago, there were two major options. Today there are six. Next year there might be twelve.
Each new tool that supports any form of hook, callback, or event system can get a theGuard adapter. The adapter implementation is typically a few hundred lines of code. The safety logic, all 170 rules, the MCP proxy, the email verification, the loop detection, all of it comes for free.
The goal is that when a new AI coding tool launches, theGuard can support it within days, not months. One interface, any number of implementations, and a shared safety layer that keeps getting stronger as the rule registry grows. The tools change. The safety requirements do not.