# How Windows-Specific DCG Packs Differ from Unix Pack Implementations

> Discover how Windows dcg packs adapt Destructive Command Guard for cmd.exe and PowerShell, differing from Unix pack implementations targeting case-sensitive Linux and macOS utilities.

- Repository: [Jeff Emanuel/destructive_command_guard](https://github.com/Dicklesworthstone/destructive_command_guard)
- Tags: deep-dive
- Published: 2026-07-13

---

**Windows-specific dcg packs adapt the shared Destructive Command Guard architecture to case-insensitive cmd.exe and PowerShell syntax while Unix packs target case-sensitive Linux and macOS utilities.**

The Destructive Command Guard (dcg) repository provides platform-specific protection against destructive shell commands. While both Windows and Unix implementations share the same core architecture—Aho-Corasick keyword quick-reject followed by regex evaluation—they diverge significantly in command vocabulary, case sensitivity handling, and safe-pattern recognition according to the source code in [`src/packs/windows/mod.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/mod.rs).

## Command Vocabulary and Target Shells

Unix packs target traditional POSIX utilities such as `rm`, `git`, and `docker`. In contrast, Windows-specific dcg packs focus on native Windows verbs and PowerShell cmdlets.

**Windows packs** monitor `cmd.exe` commands including `del`, `erase`, `rd`, and `format`, alongside PowerShell cmdlets like `Remove-Item`, `Clear-Content`, and `Clear-RecycleBin`. This specialized vocabulary ensures that Windows-specific destructive actions—such as `format C:` or `rd /s`—trigger appropriate guards with specific rule IDs like `windows.filesystem:format-drive`.

## Case Sensitivity and the Quick-Reject Path

The most critical architectural difference lies in case sensitivity. Unix commands are case-sensitive, so Unix packs store quick-reject keywords exactly as they appear. Windows commands are case-insensitive, requiring a dual-strategy approach implemented in [`src/packs/windows/filesystem.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/filesystem.rs).

**Regex matching** uses an inline `(?i)` flag in every Windows pack regex to provide case-insensitive matching. However, the **quick-reject keyword matcher** remains case-sensitive for performance. To prevent premature filtering, Windows packs enumerate **realistic casings** in their keyword lists: lower and UPPER case for `cmd` verbs (e.g., `"del"`, `"DEL"`), and PascalCase plus lower case for PowerShell cmdlets (e.g., `"Remove-Item"`, `"remove-item"`, `"REMOVE-ITEM"`).

This design ensures that the Aho-Corasick hot-path does not filter out Windows commands simply because they use different casing, while the authoritative regex matching still handles case insensitivity via the `(?i)` flag. The test `keyword_quick_reject_passes_windows_verbs_both_cases` verifies this behavior.

## Default Enablement and Platform Gating

Unix packs are enabled on all platforms via `PacksConfig::enabled_pack_ids`. Windows packs follow a different registration strategy to avoid performance costs on Unix machines.

In [`src/packs/windows/mod.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/mod.rs), Windows packs are **registered on every platform** but are **default-ON only when compiling for Windows** using the `cfg(windows)` attribute. This avoids any quick-reject cost on Unix machines while still allowing the packs to be opt-in for CI scans of `.cmd` or `.ps1` scripts on Linux or macOS build agents.

## Safe-Pattern Strategies

While Unix packs emphasize `--dry-run` and `-n` flags, Windows packs introduce platform-specific safety hooks defined in [`src/packs/windows/filesystem.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/filesystem.rs).

**Windows safe patterns** include:
- **`-WhatIf`** for PowerShell cmdlets (caught by the `whatif-preview` pattern)
- **Temporary directory scoping** allowing deletes only within `%TEMP%` or `$env:TEMP`
- **Help flags** such as `del /?` or `rd /?` that display documentation rather than execute

When these patterns are detected, the command is permitted to proceed without triggering a denial.

## Destructive-Pattern Semantics

Windows packs capture Windows-specific destructive actions that have no Unix equivalent, each with stable rule IDs for precise remediation.

**Destructive patterns** in [`src/packs/windows/filesystem.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/filesystem.rs) include:
- **`del /s`** (recursive delete) → rule ID `windows.filesystem:del-recursive`
- **`rd /s`** (recursive directory removal)
- **`format <drive>:`** (disk formatting) → rule ID `windows.filesystem:format-drive`
- **`Remove-Item -Recurse -Force`** and its aliases (`rm`, `ri`, `del`)
- **`Clear-Content`** and **`Clear-RecycleBin`**

## Practical Examples

### Blocking Recursive Deletes in cmd.exe

A recursive delete command triggers the `del-recursive` pattern:

```bash
$ echo '{"tool_name":"Bash","tool_input":{"command":"del /s /q C:\\src"}}' | dcg

```

The output shows a denial with specific remediation:

```json
{
  "hookSpecificOutput": {
    "permissionDecision":"deny",
    "ruleId":"windows.filesystem:del-recursive",
    "packId":"windows.filesystem",
    "severity":"critical",
    "remediation":{
      "safeAlternative":"Scope the path precisely and drop /q so deletions are confirmed",
      "allowOnceCommand":"dcg allow-once <code>"
    }
  }
}

```

### Allowing Safe PowerShell Previews

Commands containing `-WhatIf` are permitted by the safe pattern:

```powershell

# This command is allowed because of -WhatIf

Remove-Item -Recurse -Force C:\src -WhatIf

```

### Enabling Windows Packs on Unix Systems

To scan Windows scripts on a Linux machine, enable the packs in `~/.config/dcg/config.toml`:

```toml
[packs]
enabled = [
    "windows.filesystem",
    "windows.powershell",
    "windows.misc",
    "windows.system"
]

```

Running `dcg scan .` will now evaluate `.cmd` and `.ps1` scripts using the Windows-specific rules.

### Explaining Blocked Commands

Use `dcg explain` to see why a command is blocked:

```bash
dcg explain "format C: /q /y"

```

This references the `format-drive` destructive pattern in [`filesystem.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/filesystem.rs) and outputs the specific rule ID and remediation guidance.

## Key Implementation Files

The Windows-specific logic is distributed across these source files:

- **[`src/packs/windows/mod.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/mod.rs)**: Registers packs, documents case-insensitivity conventions, and controls default enablement via `cfg(windows)`
- **[`src/packs/windows/filesystem.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/filesystem.rs)**: Defines keywords, safe patterns, destructive patterns, and remediation suggestions
- **[`src/packs/windows/powershell.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/powershell.rs)**: Provides PowerShell-specific patterns beyond generic filesystem operations
- **[`src/packs/windows/misc.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/misc.rs)**: Covers miscellaneous commands like `shutdown` and `taskkill`
- **[`src/packs/windows/system.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/system.rs)**: Handles system-level actions such as service manipulation and registry edits

## Summary

- **Windows-specific dcg packs** target `cmd.exe` verbs and PowerShell cmdlets, while Unix packs focus on POSIX utilities
- **Case insensitivity** is handled via `(?i)` regex flags and enumerated keyword casings (e.g., `"del"`, `"DEL"`, `"Remove-Item"`) to maintain quick-reject performance
- **Default enablement** uses `cfg(windows)` to activate packs only on Windows, though they can be manually enabled for cross-platform CI scanning
- **Safe patterns** recognize Windows-specific flags like `-WhatIf`, temporary directory scoping, and help flags
- **Destructive patterns** include Windows-specific actions such as `format`, `del /s`, and `Clear-RecycleBin` with stable rule IDs like `windows.filesystem:del-recursive`

## Frequently Asked Questions

### How does dcg handle case sensitivity in Windows commands?

Windows commands are case-insensitive, so dcg embeds `(?i)` flags in Windows pack regexes. The quick-reject Aho-Corasick matcher remains case-sensitive, so the packs enumerate multiple casings (e.g., `"del"`, `"DEL"`, `"Remove-Item"`, `"remove-item"`) in the keyword list to ensure Windows commands are not prematurely filtered out before reaching the regex stage.

### Can I use Windows dcg packs on Linux or macOS?

Yes. Windows packs are registered globally but default to OFF on non-Windows systems. You can enable them manually in `~/.config/dcg/config.toml` by adding the Windows pack IDs to the `enabled` list. This supports CI pipelines that need to scan Windows scripts (`cmd` or `ps1`) from Unix build agents.

### What is the difference between safe patterns in Windows and Unix packs?

Unix safe patterns emphasize `--dry-run` and preview flags. Windows safe patterns additionally recognize PowerShell's `-WhatIf` parameter, allow operations confined to temporary directories (`%TEMP%`, `$env:TEMP`), and permit help flags like `del /?` that display documentation rather than execute destructive actions.

### How are PowerShell aliases handled in dcg?

Windows packs account for PowerShell aliases by including them in destructive pattern definitions. For example, the `Remove-Item` pattern also matches its aliases `rm`, `ri`, and `del`, ensuring that destructive commands using shorthand notation are caught regardless of whether the user types the full cmdlet name or the alias.