Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Exec preflight "command too long" triggers misleading approval-gate error when approvals are disabled [3 pull requests, 3 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#61600•Fetched 2026-04-08 02:56:58
View on GitHub
Comments
3
Participants
2
Timeline
6
Reactions
0
Author
slideshow-dingoslideshow-dingo
Participants
slideshow-dingoslideshow-dingoSnowSky1SnowSky1
Timeline (top)
commented ×3cross-referenced ×3

Error Message

When the exec preflight heuristic fires with "Command too long; potential obfuscation", the gateway surfaces a user-facing error that incorrectly references exec approvals: When exec preflight blocks a command due to the obfuscation/length heuristic, the error message should:

Fix Action

Fixed

PR fix notes

PR #61791: fix(exec): clarify preflight obfuscation guidance

Description (problem / solution / changelog)

Summary

  • detect exec preflight obfuscation warnings before falling back to approval-unavailable guidance
  • explain that the command was blocked by exec preflight, not by the approvals subsystem
  • point users at \ ools.exec.maxCommandChars\ and \ ools.exec.obfuscationCheck: false\
  • add focused reply helper coverage for the obfuscation warning path

Closes #61600

Verification

  • \pnpm exec oxfmt --check src/infra/exec-approval-reply.ts src/infra/exec-approval-reply.test.ts\
  • direct runtime assertion for \uildExecApprovalUnavailableReplyPayload(...)\ on the obfuscation warning path

Changed files

  • src/infra/exec-approval-reply.test.ts (modified, +16/-0)
  • src/infra/exec-approval-reply.ts (modified, +21/-0)

PR #61806: fix(exec): clarify preflight obfuscation guidance

Description (problem / solution / changelog)

Summary

  • detect exec preflight obfuscation warnings before falling back to approval-unavailable guidance
  • explain that the command was blocked by exec preflight, not by the approvals subsystem
  • point users at \ ools.exec.maxCommandChars\ and \ ools.exec.obfuscationCheck: false\
  • add focused reply helper coverage for the obfuscation warning path

Closes #61600

Verification

  • \pnpm exec oxfmt --check src/infra/exec-approval-reply.ts src/infra/exec-approval-reply.test.ts\
  • direct runtime assertion for \uildExecApprovalUnavailableReplyPayload(...)\ on the obfuscation warning path

Changed files

  • src/infra/exec-approval-reply.test.ts (modified, +17/-0)
  • src/infra/exec-approval-reply.ts (modified, +21/-0)

PR #61842: fix(exec-approval): distinguish preflight rejection from approval gate

Description (problem / solution / changelog)

Fix Summary

When the exec preflight heuristic fires (e.g. "Command too long; potential obfuscation"), the current code surfaces a user-facing error that incorrectly references exec approvals:

Exec approval is required, but no interactive approval client is currently available.

This message is shown even when approvals are disabled. The preflight rejection has nothing to do with the approval subsystem.

Changes

File: src/infra/exec-approval-reply.ts

  1. Added preflight-rejected to the ExecApprovalUnavailableReason discriminated union type
  2. Added a new branch in buildExecApprovalUnavailableReplyPayload that handles reason === "preflight-rejected" with a message that:
    • Clearly states this is a preflight rejection, not an approval gate
    • Shows the specific preflight reason (e.g. the warning text)
    • Points users to the correct config fixes: tools.exec.obfuscationCheck: false and tools.exec.maxCommandChars: <number>

Before vs After

Before: User sees approval-gate message directing them to configure an approval system that cannot resolve the actual problem.

After: User sees "Exec preflight rejected this command — this is not an approval gate" with the specific preflight reason and correct config workarounds.

Fixes #61600

Changed files

  • src/infra/exec-approval-reply.ts (modified, +24/-1)

Code Example

⚠️ Obfuscated command detected: Command too long; potential obfuscation

Exec approval is required, but chat exec approvals are not enabled on Discord.

Approve it from the Web UI or terminal UI, or enable a native chat approval client such as Discord, Slack, or Telegram.

---

{
  "approvals": { "exec": { "enabled": false } },
  "channels": {
    "discord": {
      "execApprovals": { "enabled": false }
    }
  }
}

---

[exec] obfuscation detected (gateway): Command too long; potential obfuscation
RAW_BUFFERClick to expand / collapse

Bug Description

When the exec preflight heuristic fires with "Command too long; potential obfuscation", the gateway surfaces a user-facing error that incorrectly references exec approvals:

⚠️ Obfuscated command detected: Command too long; potential obfuscation

Exec approval is required, but chat exec approvals are not enabled on Discord.

Approve it from the Web UI or terminal UI, or enable a native chat approval client such as Discord, Slack, or Telegram.

This message is shown even when approvals.exec.enabled: false and channels.discord.execApprovals.enabled: false — i.e., when there is no approval system in use at all. The preflight rejection has nothing to do with the approval subsystem.

Expected Behavior

When exec preflight blocks a command due to the obfuscation/length heuristic, the error message should:

  1. Clearly indicate it is a preflight rejection, not an approval gate
  2. Either suggest the correct config fix (tools.exec.obfuscationCheck: false or tools.exec.maxCommandChars) or direct users to documentation

The current message is doubly harmful:

  • It tells the user to enable chat exec approvals, which does not resolve the preflight block
  • It makes it appear that OpenClaw's approval system is involved when it is not

Steps to Reproduce

  1. Set approvals.exec.enabled: false and channels.discord.execApprovals.enabled: false
  2. Issue a command whose rendered text (after context interpolation) exceeds the preflight length threshold — e.g., a long inline script or a command with many flag expanded from context
  3. Observe the obfuscation preflight fires with: exec preflight: obfuscation detected (gateway): Command too long; potential obfuscation
  4. The user sees the approval-gate fallback message in Discord

Minimal repro config:

{
  "approvals": { "exec": { "enabled": false } },
  "channels": {
    "discord": {
      "execApprovals": { "enabled": false }
    }
  }
}

Impact

  • Confusion: Users with exec approvals disabled are told to enable exec approvals as a fix — which is wrong
  • Wrong diagnosis path: Time wasted configuring an approval system that cannot resolve the actual problem
  • Trust erosion: The system appears to have a broken approval mechanism even when it is correctly disabled

Suggested Fix

Two parts:

  1. Fix the user-facing message in src/infra/exec-approval-reply.ts (or equivalent fallback path): distinguish preflight rejections from approval requests. The preflight block should never emit the approval-gate UI text.

  2. Document the real fixes for this preflight block:

    • tools.exec.obfuscationCheck: false (added in #50295 / PR #60709 — already merged)
    • tools.exec.maxCommandChars: <number> (added in #55802 — already merged)

Additional Context

  • Related: #53250 (UX: exec approval timeout message should include Control UI link and setup hints) — covers a similar message-quality issue
  • Related: #55802 (feat: make exec obfuscation command length threshold configurable) — threshold config already exists
  • Related: #50295 (feat: add tools.exec.obfuscationCheck config option) — obfuscation check bypass already exists
  • OpenClaw version: 2026.4.2 (d74a122)
  • Install method: npm global (openclaw CLI)

Gateway log excerpt:

[exec] obfuscation detected (gateway): Command too long; potential obfuscation

No approval-related log lines appear around this event — confirming the approval subsystem is not involved.

extent analysis

TL;DR

Update the user-facing error message in src/infra/exec-approval-reply.ts to distinguish preflight rejections from approval requests and document the real fixes for the preflight block.

Guidance

  • Review the src/infra/exec-approval-reply.ts file to identify where the approval-gate fallback message is being emitted and update it to handle preflight rejections separately.
  • Verify that the updated message clearly indicates a preflight rejection and suggests the correct config fixes (tools.exec.obfuscationCheck: false or tools.exec.maxCommandChars) or directs users to documentation.
  • Test the updated message by reproducing the issue with the minimal repro config and checking that the new message is displayed.
  • Consider adding documentation for the tools.exec.obfuscationCheck and tools.exec.maxCommandChars config options to help users understand how to resolve the preflight block.

Example

No code snippet is provided as the issue does not contain enough information to create a specific example.

Notes

The fix may require additional changes to the approval subsystem or the preflight block logic, but the provided information only suggests updating the user-facing error message.

Recommendation

Apply a workaround by updating the src/infra/exec-approval-reply.ts file to handle preflight rejections separately and document the real fixes for the preflight block, as the approval subsystem is not involved in this issue.

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…
#device allocation#model download#tokenizer error#prompt formatting#chain error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Exec preflight "command too long" triggers misleading approval-gate error when approvals are disabled [3 pull requests, 3 comments, 2 participants]