# How to Configure Agent-Specific Profiles for Different AI Coding Agents in dcg

> Learn how to configure agent-specific profiles for AI coding agents in dcg using TOML files and environment variables. Customize your AI assistant's behavior easily.

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

---

**You can configure agent-specific profiles in dcg by creating a TOML file with `[agents.<name>]` tables, setting `agent_specific = true` under `[policy]`, and allowing dcg to detect the active AI agent through environment variables or the `--agent` CLI flag.**

Dicklesworthstone/destructive_command_guard (dcg) provides granular control over command execution policies by supporting agent-specific profiles. This system lets you define distinct security postures for different AI coding assistants—such as Claude, Codex, Gemini, and Aider—based on their unique risk characteristics and trust levels. Understanding how to configure agent-specific profiles for different AI coding agents in dcg allows you to apply stricter scrutiny to high-risk agents while maintaining productivity with trusted tools.

## Understanding Agent-Specific Profile Settings

Each agent profile in dcg defines a customized security posture through specific configuration keys. When you create a profile under `[agents.<agent_name>]`, you control how the guard evaluates commands issued by that particular AI assistant.

The available settings include:

- **strictness**: Defines aggression level (`low`, `medium`, `high`) for command evaluation
- **enabled_packs**: Specifies which pattern detection packs are active for the agent
- **default_mode**: Sets the baseline action (`allow`, `warn`, `log`, `deny`) when no specific rule matches
- **log_all_decisions**: Boolean flag to write every evaluation to the history database
- **require_confirmation**: Controls whether user confirmation is needed for flagged commands
- **require_bypass_confirmation**: Determines if bypass operations need explicit approval
- **max_warnings_per_session**: Rate-limits warnings to prevent notification fatigue
- **trust_level**: Numeric value (1-10) where higher values enable more permissive defaults

When no matching profile exists for a detected agent, dcg falls back to the `[agents.default]` table.

## Configuration File Structure and Location

Agent profiles reside in a TOML configuration file that dcg loads at startup. The reference implementation in [`tests/e2e/fixtures/configs/agent_profiles.toml`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/tests/e2e/fixtures/configs/agent_profiles.toml) demonstrates the complete schema, defining profiles for Claude, Codex, Cursor, Copilot, Continue.dev, and Aider alongside a default fallback.

To enable agent-specific handling, you must set `agent_specific = true` in the `[policy]` section of your configuration:

```toml
[policy]
agent_specific = true
enabled = true
default_mode = "warn"

```

The test suite embeds this configuration through the `AGENT_PROFILES_CONFIG` constant defined in [`tests/e2e/framework.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/tests/e2e/framework.rs) at lines 652-660. In production, dcg searches for the configuration file at `~/.config/dcg/config.toml` by default, or you can specify a custom path via the `--config` flag or `DCG_CONFIG` environment variable.

## Agent Detection Mechanism

Dcg automatically identifies the active AI coding agent by inspecting specific environment variables. The detection logic checks for the following variables in order of precedence:

| Environment Variable | Detected Agent |
|---|---|
| `CLAUDE_CODE` | Claude Code |
| `AIDER_SESSION` | Aider |
| `CONTINUE_SESSION_ID` | Continue.dev |
| `CODEX_CLI` | Codex |
| `GEMINI_CLI` | Gemini |
| `COPILOT_CLI` or `COPILOT_AGENT_START_TIME_SEC` | Copilot |
| `DCG_AGENT_TYPE` | Custom agent name (fallback) |

When multiple variables are present, the first match in this hard-coded order wins, as validated in [`tests/agent_profile_comprehensive.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/tests/agent_profile_comprehensive.rs) within the edge cases module. You can explicitly override automatic detection by passing the `--agent <name>` flag, which takes precedence over all environment variables.

## Loading and Merging Profile Logic

When `agent_specific` is enabled in the policy configuration, dcg executes a multi-step loading process implemented in [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs):

1. **File Resolution**: Locate the TOML file via `--config`, `DCG_CONFIG`, or default paths
2. **Agent Identification**: Determine the agent name from environment variables or CLI flags
3. **Table Extraction**: Retrieve the `[agents.<agent_name>]` section (case-insensitive matching)
4. **Fallback Merge**: Apply missing fields from `[agents.default]` to create the final configuration
5. **Pipeline Integration**: Feed the merged settings into the evaluation engine to control pack activation and decision modes

This merging strategy ensures that you only need to specify deviations from your baseline policy. For example, if `[agents.default]` sets `strictness = "medium"` but you define `strictness = "high"` for `[agents.claude_code]`, Claude inherits all other settings from the default while using the elevated strictness level.

## Practical Configuration Examples

### Running dcg with a Custom Agent Profile

Load a specific configuration file and target the Claude profile to apply high-strictness monitoring:

```bash
DCG_CONFIG=./tests/e2e/fixtures/configs/agent_profiles.toml dcg --agent claude_code test "git status"

```

This command applies the Claude-specific settings from the TOML file, which typically configures `strictness = "high"` and `default_mode = "deny"` for maximum protection.

### Overriding Automatic Detection

Force dcg to use a specific agent profile regardless of environment variables:

```bash
dcg --agent my-custom-agent --config ./tests/e2e/fixtures/configs/agent_profiles.toml test "npm run build"

```

If `[agents.my-custom-agent]` does not exist in the configuration, dcg seamlessly falls back to `[agents.default]`.

### Adjusting Trust Levels Dynamically

Temporarily elevate trust for a single session without modifying the configuration file:

```bash
DCG_TRUST_LEVEL=9 dcg test "git push --force"

```

Higher trust levels relax enforcement thresholds, useful when working with well-tested automation scripts.

### Disabling Agent-Specific Handling

To use a uniform policy across all AI agents, disable the feature in your configuration:

```bash
dcg --config ./uniform_policy.toml test "rm -rf ./temp"

```

Ensure that [`uniform_policy.toml`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/uniform_policy.toml) contains `[policy].agent_specific = false` to ignore environment-derived agent names.

## Summary

- **Agent-specific profiles** in dcg allow tailored security policies for individual AI coding assistants through TOML configuration files
- **Detection relies** on environment variables like `CLAUDE_CODE`, `AIDER_SESSION`, and `CODEX_CLI`, with `DCG_AGENT_TYPE` serving as a custom fallback
- **Configuration requires** `agent_specific = true` in the `[policy]` section and `[agents.<name>]` tables for each AI assistant
- **Fallback behavior** automatically merges unspecified profile fields from `[agents.default]`, ensuring complete configuration coverage
- **CLI overrides** via `--agent` and `--config` flags enable testing and deployment flexibility without modifying environment variables

## Frequently Asked Questions

### How does dcg detect which AI agent is running?

Dcg inspects a prioritized list of environment variables specific to each AI coding assistant. It checks for `CLAUDE_CODE`, `AIDER_SESSION`, `CONTINUE_SESSION_ID`, `CODEX_CLI`, `GEMINI_CLI`, and `COPILOT_CLI` (or `COPILOT_AGENT_START_TIME_SEC`) in sequence, using the first match found. If none of these are present, it falls back to `DCG_AGENT_TYPE`. This logic is exercised in [`tests/agent_profile_comprehensive.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/tests/agent_profile_comprehensive.rs) at lines 41-48.

### What happens if no profile exists for the detected agent?

If dcg detects an agent name but cannot find a matching `[agents.<name>]` table in the configuration file, it automatically merges the detected agent name with the `[agents.default]` profile. This ensures that unknown or custom agents still operate under your baseline security policy rather than failing or running unrestricted.

### Can I override the automatic agent detection?

Yes. You can bypass the environment variable detection entirely by using the `--agent <name>` CLI flag. This explicit declaration takes precedence over all environment variables, as demonstrated in the `test_explicit_agent_flag_override` test case within [`tests/agent_profile_comprehensive.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/tests/agent_profile_comprehensive.rs) (lines 66-73). This is useful for testing profiles or running dcg in environments where you cannot modify environment variables.

### Where should I place my custom agent profiles TOML file?

While dcg checks `~/.config/dcg/config.toml` by default, you can place your configuration file anywhere and reference it via the `--config` flag or the `DCG_CONFIG` environment variable. For reference implementations, examine [`tests/e2e/fixtures/configs/agent_profiles.toml`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/tests/e2e/fixtures/configs/agent_profiles.toml), which contains working examples for Claude, Codex, Cursor, Copilot, Continue.dev, and Aider profiles.