# How to Integrate dcg with VS Code Copilot Chat and Cursor IDE

> Integrate dcg with VS Code Copilot Chat and Cursor IDE. Install the binary and configure the JSON hook to route PreToolUse payloads, blocking destructive commands and ensuring safe operations.

- Repository: [Jeff Emanuel/destructive_command_guard](https://github.com/Dicklesworthstone/destructive_command_guard)
- Tags: how-to-guide
- Published: 2026-07-14

---

**Integrate dcg with VS Code Copilot Chat and Cursor IDE by installing the binary with `dcg install` and placing a JSON hook file in the IDE-specific hooks directory, which routes PreToolUse payloads through the Rust-based guard to block destructive commands while allowing safe operations.**

Dicklesworthstone/destructive_command_guard is a Rust-based safety interceptor that evaluates shell commands against curated whitelist and blacklist patterns. When you integrate dcg with VS Code Copilot Chat and Cursor IDE, every AI-generated terminal command passes through the evaluation engine in [`src/evaluator.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/evaluator.rs) before execution, returning either silent approval or a structured JSON denial with remediation suggestions.

## How the PreToolUse Hook Protocol Works

Both VS Code Copilot Chat and Cursor IDE implement the **PreToolUse** hook protocol that dcg supports. When the AI agent requests terminal command execution, it emits a JSON payload containing a `tool_name` (such as `runTerminalCommand`, `run_in_terminal`, or `runInTerminal`) and the raw command string. According to [`src/hook.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/hook.rs), dcg reads this payload from standard input, parses the command through [`src/normalize.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/normalize.rs) for path stripping and alias expansion, then evaluates it against safe and destructive patterns in [`src/evaluator.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/evaluator.rs).

## Installing dcg and Configuring IDE Hooks

Integration requires two steps: installing the dcg binary and creating the hook configuration file that points the IDE to the executable.

### Installing the dcg Binary

In [`src/cli.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/cli.rs), the `install` sub-command handles copying the platform-specific binary (`dcg.exe` on Windows, `dcg` on Unix) to `%USERPROFILE%\.dcg` or `~/.local/bin` and automatically appends the location to your `PATH` environment variable.

```bash
curl -L https://github.com/Dicklesworthstone/destructive_command_guard/releases/latest/download/dcg-installer.sh | sh -s -- -EasyMode

```

This single command downloads the release and configures the binary for use with all supported agents.

### Configuring the Hook for VS Code Copilot Chat

For VS Code Copilot Chat, the installer creates a JSON file at `~/.config/Code/User/agent-hooks/dcg.json` (or the platform-specific path shown by `dcg install --help`). As documented in [`docs/agents.md`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/docs/agents.md), this file tells the agent runtime to invoke dcg with stdin/stdout connected to the hook payload:

```json
{
  "tool_name": "runTerminalCommand",
  "executable": "dcg",
  "args": [],
  "stdin_from_tool": true,
  "stdout_to_tool": true
}

```

### Configuring the Hook for Cursor IDE

For Cursor IDE, place the same JSON configuration in `~/.cursor/hooks/dcg.json`. The schema remains identical to the VS Code Copilot Chat configuration, as both agents use the same protocol structure. The [`docs/windows.md`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/docs/windows.md) file documents Windows-specific path variations for GitHub Copilot CLI, while Cursor uses the Unix-style path above on macOS and Linux.

## The Command Evaluation Flow

When you prompt Copilot Chat or Cursor to execute a terminal command, the IDE sends a JSON payload to dcg via standard input. The structure includes the tool identifier and the command to execute:

```json
{
  "tool_name": "runTerminalCommand",
  "tool_input": { "command": "rm -rf node_modules" }
}

```

In [`src/hook.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/hook.rs), dcg processes this payload through a deterministic pipeline:

1. **Fast-reject filter**: Immediately allows obviously benign commands
2. **Normalization**: Strips paths and expands aliases using logic in [`src/normalize.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/normalize.rs)
3. **Pattern matching**: Checks against destructive patterns in [`src/evaluator.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/evaluator.rs)
4. **Decision**: Writes empty output to stdout for allowed commands, or structured denial JSON for blocked commands

For example, `rm -rf node_modules` matches the safe pattern `rm-tmp`, so dcg returns no output and execution proceeds. However, `git reset --hard HEAD~5` triggers a destructive match, causing dcg to emit a denial JSON that the IDE displays as a warning in the chat pane.

## Managing Blocked Commands with Allow-Once Codes

When dcg blocks a destructive command, the denial JSON includes an **allow-once code** generated by the logic in [`src/suggestions.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/suggestions.rs). To execute the blocked command a single time without permanently modifying the rules, run:

```bash
dcg allow-once a1b2c3

```

This grants temporary permission for that specific command within the current directory scope for 24 hours. After the timeout expires or the scope changes, dcg resumes blocking the pattern. The [`src/cli.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/cli.rs) module handles the `allow-once` sub-command by updating the local state store.

## Summary

- Install dcg using the automated installer, which places the binary in `~/.local/bin` (or `%USERPROFILE%\.dcg` on Windows) and updates `PATH` via [`src/cli.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/cli.rs)
- Configure VS Code Copilot Chat with a JSON hook in `~/.config/Code/User/agent-hooks/dcg.json` and Cursor IDE in `~/.cursor/hooks/dcg.json`
- dcg intercepts PreToolUse payloads in [`src/hook.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/hook.rs) and evaluates commands through the whitelist/blacklist engine in [`src/evaluator.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/evaluator.rs)
- Blocked commands return structured JSON containing remediation suggestions and allow-once codes managed by [`src/suggestions.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/suggestions.rs)
- Use `dcg allow-once <code>` to bypass specific restrictions temporarily for 24 hours

## Frequently Asked Questions

### Where does dcg store its configuration and hook files?

dcg stores the executable in `%USERPROFILE%\.dcg` on Windows or `~/.local/bin` on Unix systems, as implemented in [`src/cli.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/cli.rs). Hook configurations reside in IDE-specific directories: `~/.config/Code/User/agent-hooks/` for VS Code Copilot Chat and `~/.cursor/hooks/` for Cursor IDE, documented in [`docs/windows.md`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/docs/windows.md) and the repository README.

### Can I use dcg with both VS Code Copilot Chat and Cursor simultaneously?

Yes. Since dcg is a standalone binary, install it once and create separate hook JSON files in each IDE's hooks directory. Both agents invoke the same dcg executable independently, and each maintains its own allow-once state scoped to the working directory.

### What happens if dcg blocks a command I need to run?

When dcg blocks a command, it returns a denial JSON containing an `allowOnceCode`. You can execute `dcg allow-once <code>` to permit the command for the next 24 hours in the current directory, or you can modify the whitelist patterns in the dcg configuration to permanently allow the command type.

### How does dcg handle complex shell commands with pipes and redirects?

In [`src/normalize.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/normalize.rs), dcg normalizes the command string by stripping variable paths and expanding aliases before pattern matching in [`src/evaluator.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/evaluator.rs). The evaluator analyzes the normalized command as a complete string against destructive patterns, ensuring that pipes, redirects, and chained commands are evaluated in their full context rather than as isolated components.