Configurable host-protection hooks: regex-based action blocking

[aniongithub]

Summary

Extend the host-protection hooks (added in #16) to support configurable regex patterns that block specific commands or classes of commands on the host. This gives users fine-grained control beyond the current binary "devcontainer exists → block all bash" behavior.

Motivation

The current hooks block all shell execution when a devcontainer is detected. But even in projects without devcontainers, users may want to prevent agents from running destructive commands on the host — rm -rf, git push --force, sudo, dd, package manager installs, etc.

Proposed design

A configuration file (e.g. ~/.config/devcontainer-mcp/guard-rules.json) with an array of regex patterns:

{
  "block": [
    { "pattern": "rm\\s+(-[^\\s]*)?\\s*-r", "reason": "Recursive delete blocked" },
    { "pattern": "sudo\\s+", "reason": "Elevated privileges blocked" },
    { "pattern": "git\\s+push\\s+.*--force", "reason": "Force push blocked" },
    { "pattern": "dd\\s+", "reason": "Raw disk write blocked" },
    { "pattern": ":(){ :|:& };:", "reason": "Fork bomb blocked" },
    { "pattern": "curl.*\\|\\s*(ba)?sh", "reason": "Pipe-to-shell blocked" },
    { "pattern": "npm\\s+publish", "reason": "Package publish blocked" },
    { "pattern": "pip\\s+install(?!.*--user)", "reason": "System-wide pip install blocked" }
  ]
}

Each rule has:

• pattern — regex matched against the tool input (command string)
• reason — message returned to the agent explaining why it was blocked

Behavior

1. Hook reads the config file on each invocation (or caches with mtime check)
2. For each block rule, test the regex against the command
3. If any rule matches → deny with the rule's reason
4. The existing devcontainer check and USER_CONFIRMED_HOST_OPERATION=1 bypass still apply (bypass skips regex checks too)

Scope

• The regex rules apply to host tool calls only — commands routed through devcontainer-mcp MCP tools (devpod_ssh, devcontainer_exec, codespaces_ssh) are inside containers and not subject to these rules
• Ship a sensible default rule set that users can extend or override
• The install scripts should create the config with defaults

Open questions

• Should there also be an allow list (allowlist takes priority over blocklist)?
• Should rules support per-project overrides (e.g. .devcontainer-mcp/guard-rules.json in repo root)?
• Should the config support rule severity levels (block vs warn)?