How the Pack Enable/Disable System Works with Category Expansion in dcg

The destructive-command-guard (dcg) implements hierarchical pack control through prefix-based category expansion in src/config.rs, where disabling a parent category automatically disables all descendant packs while keeping the core pack mandatory and system.disk opt-out by default.

The dcg repository organizes destructive pattern detection into modular packs that users can toggle via configuration files. Understanding how the pack enable/disable system with category expansion works is critical for customizing protection levels without accidentally exposing dangerous commands. The logic resides primarily in src/config.rs, where the PacksConfig::enabled_pack_ids method builds the active set using dot-separated namespace rules and conditional platform logic.

Pack ID Hierarchy and Configuration Structure

Packs in dcg follow a dot-separated namespace (e.g., core.git, system.disk, windows.filesystem). The configuration in ~/.config/dcg/config.toml supports three top-level keys under [packs]:

• enabled – Explicit pack IDs to activate.
• disabled – Explicit pack IDs to deactivate.
• custom_paths – External files defining additional packs.

This hierarchy allows fine-grained control. For example, system acts as a category parent to system.disk, while windows encompasses windows.filesystem and windows.system.

The Expansion Algorithm in src/config.rs

The core logic lives in PacksConfig::enabled_pack_ids within src/config.rs. The method constructs a HashSet<String> of active packs through five deterministic steps:

let mut enabled: HashSet<String> = self.enabled.iter().cloned().collect(); // 1

// 2 – Remove disabled packs and their sub‑packs
for disabled in &self.disabled {
    enabled.remove(disabled);
    enabled.retain(|p| !p.starts_with(&format!("{disabled}.")));
}

// 3 – Core is always on
enabled.insert("core".to_string());

// 4 – system.disk default‑on unless disabled
let sys_disk_disabled = self.disabled.iter().any(|d| d == "system.disk" || d == "system");
if !sys_disk_disabled {
    enabled.insert("system.disk".to_string());
}

// 5 – Windows packs default‑on only on Windows
#[cfg(windows)]
{
    for pack_id in ["windows.filesystem", "windows.system"] {
        let disabled = self.disabled.iter().any(|d| d == pack_id || d == "windows");
        if !disabled {
            enabled.insert(pack_id.to_string());
        }
    }
}

Step 1: Base Enable Set Minus Explicit Disables

The algorithm begins by cloning the enabled list into a mutable HashSet. It then removes any IDs found in the disabled list. This handles direct conflicts where a pack appears in both lists.

Step 2: Category-Wide Disabling via Prefix Matching

Category expansion occurs during the disable phase. For each entry in disabled, the code removes not only the exact match but also any pack whose ID starts with that prefix followed by a dot:

enabled.retain(|p| !p.starts_with(&format!("{disabled}.")));

This means disabling system automatically excludes system.disk, system.network, and any future system.* packs. The expansion is unidirectional downward—parent disables propagate to children, but child disables do not affect parents.

Step 3: Mandatory and Default Packs

After processing user preferences, the system enforces two hardcoded rules:

1. core is mandatory – Inserted regardless of user settings via enabled.insert("core".to_string()).
2. system.disk is opt-out – Added automatically unless the user explicitly disables system.disk or the parent system category.

Platform-Specific Handling for Windows Packs

The algorithm handles cross-platform safety through conditional compilation. On Windows targets (#[cfg(windows)]), the code iterates over ["windows.filesystem", "windows.system"] and adds each to the enabled set unless disabled directly or via the windows category parent.

On non-Windows platforms, these packs remain registered but inactive by default. Unix users can opt-in by manually adding them to enabled, allowing PowerShell script scanning even on Linux hosts.

Agent-Specific Pack Resolution

When running under specific agents (e.g., Claude Code), dcg calls enabled_pack_ids_for_agent instead of the base method. According to the source in src/main.rs, this variant:

1. Starts with the base set from enabled_pack_ids().
2. Adds any extra packs the agent declares as required.

This allows CI/CD agents to inject additional protection packs without modifying the user's global configuration.

Practical Configuration Examples

Enable Specific Packs

Add explicit pack IDs to activate custom protection:

[packs]
enabled = ["database.postgresql", "cloud.aws"]

Disable an Entire Category

Prevent all system-related packs by disabling the parent category:

[packs]
disabled = ["system"]

This removes system.disk and any future system.* packs automatically.

Fine-Grained Windows Control

Enable the windows category for discovery but disable specific sub-packs:

[packs]
enabled = ["windows"]
disabled = ["windows.system"]

This keeps windows.filesystem active while excluding windows.system.

Opt-Out of Default Protections

Disable the automatic system.disk pack if your workflow requires unfettered disk operations:

[packs]
disabled = ["system.disk"]

Summary

• Category expansion propagates downward: disabling system blocks all system.* packs via prefix matching in src/config.rs.
• Explicit enables do not auto-expand; enabling windows makes packs discoverable but does not activate windows.filesystem unless configured.
• Core packs (core) are always loaded, while system packs (system.disk) are opt-out only.
• Windows-specific packs auto-enable on Windows unless explicitly disabled or the windows category is turned off.
• Agent variants (enabled_pack_ids_for_agent) allow runtime injection of additional packs on top of the base configuration.

Frequently Asked Questions

What happens if I enable a category like "windows" but disable a specific sub-pack?

Enabling a category adds only that specific ID to the active set; it does not automatically expand to children. If you enable windows but disable windows.system, the windows.filesystem pack remains inactive (unless also enabled or auto-enabled by the platform), while windows.system is explicitly excluded. This design provides fine-grained control without implicit inheritance of enable states.

Why is the "core" pack always enabled regardless of my configuration?

The core pack contains fundamental protection patterns that the dcg maintainers deem critical for safe operation. In src/config.rs, the code explicitly inserts "core" into the enabled set after processing user preferences, ensuring baseline protection cannot be accidentally disabled through configuration errors.

How do I disable the automatic system.disk protection?

Add either system.disk or the parent system category to your disabled list in ~/.config/dcg/config.toml. The logic checks self.disabled.iter().any(|d| d == "system.disk" || d == "system") before inserting the pack, so either entry prevents automatic activation.

Can Unix systems use Windows-specific packs?

Yes. While windows.filesystem and windows.system auto-enable only on Windows targets (guarded by #[cfg(windows)]), non-Windows systems can explicitly opt-in by adding these IDs to the enabled list. This allows Linux or macOS users to scan PowerShell scripts or Windows-specific commands without changing the source code.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}