How Windows-Specific DCG Packs Differ from Unix Pack Implementations

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.

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.

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, 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.

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 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:

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

The output shows a denial with specific remediation:

{
  "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:

# 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:

[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:

dcg explain "format C: /q /y"

This references the format-drive destructive pattern in 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: Registers packs, documents case-insensitivity conventions, and controls default enablement via cfg(windows)
• src/packs/windows/filesystem.rs: Defines keywords, safe patterns, destructive patterns, and remediation suggestions
• src/packs/windows/powershell.rs: Provides PowerShell-specific patterns beyond generic filesystem operations
• src/packs/windows/misc.rs: Covers miscellaneous commands like shutdown and taskkill
• 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.

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