Bug type

Regression (worked before, now fails)

Summary

from the clanker:
I’m reporting a critical runtime regression that broke autonomous operations for a live trading deployment.
This appears to be in the command-execution path (validator/policy matcher), not application logic.

Summary
OpenClaw command execution began failing with:

Invalid regular expression: /^/usr/bin/g++$/i: Nothing to repeat
This prevented agent-side command execution (exec bridge), blocking process control, validation, migration runs, and runtime recovery orchestration.
The failure caused prolonged instability during a live rollout and forced repeated manual interventions.

Primary Error Signature
Invalid regular expression: /^/usr/bin/g++$/i: Nothing to repeat

This strongly suggests an unescaped regex build from a literal binary path containing + (g++).

Observed Impact
Agent exec bridge unusable
Any command via tool runner fails instantly with regex compile error.
Host shell could still run commands in some contexts, but agent runtime path remained broken.

Autonomous orchestration broken
Could edit files via file tools, but could not reliably execute runtime control commands.
Could not complete end-to-end “fix + restart + verify” loops in one path.

Operational fallout during trading rollout
PM2/runtime control became inconsistent.
.env got corrupted during repeated manual copy/paste attempts (concatenated command text into key fields).
Historical log spam mixed multiple failure causes (enum parsing, auth failures, schema mismatch), obscuring root state.

Secondary Errors Seen (during fallout)
These are downstream effects from repeated partial recovery attempts:
Invalid env: ... Expected 'paper' | 'live', received 'liveaper'
No broker adapters configured. Add API keys to trading-lab/.env
Request failed with status code 401 (auth mismatch / base mismatch periods)
no such column: closed_at (migration drift while runtime restarted in partial states)
kraken_account_error:EAPI:Invalid nonce (when Kraken remained enabled during unstable restart loops)

Reproduction (high confidence)
Install/update OpenClaw.
Run command execution path that compiles command/binary policy matcher.
Include/resolve binary path containing regex metacharacter + (e.g. /usr/bin/g++).
Regex compilation fails due to unescaped input:
pattern shaped like ^/usr/bin/g++$ (invalid).

Expected Behavior
Command runner should treat binary paths as literal strings.
Paths with metacharacters (+, ., (, ), etc.) must not break regex compilation.
Exec bridge should remain functional after updates/restarts.

Actual Behavior
Regex compile throws and blocks command execution path.
Agent tooling reports hard failure on every exec call.
Recovery actions become fragmented and manual, even though system should be autonomous.

Suspected Root Cause
Some validator/policy path likely does:

new RegExp("^" + binaryPath + "$", "i")

without escaping binaryPath.

Should instead escape before regex construction, e.g.:

const esc = (s) => s.replace(/[.*+?^${}()|[]\]/g, '\$&')
new RegExp("^" + esc(binaryPath) + "$", "i")

Severity
High / Critical for autonomous deployments.

Why:
Breaks core command execution.
Can strand agents in partial remediation loops.
In live systems, increases risk from delayed recovery and mixed-state config/runtime mutations.

Requested Fixes
Patch regex escaping for all command/binary/path-derived regexes.
Add regression tests for:
/usr/bin/g++
/usr/local/bin/clang++
paths containing ()[]{}.+?|
Add startup self-check for command runner policy compile.
Fail-safe behavior:
if matcher compile fails, surface clear diagnostic and use safe literal fallback.
Improve observability:
expose which matcher input caused compile failure.

Suggested Regression Test Cases
Literal path matching:
/usr/bin/g++
/usr/bin/node
Escaped metacharacter handling:
+, ., (, ), [, ], {, }, ?, |
Ensure no uncaught exception from matcher creation.
Ensure deny/allow behavior remains correct with escaped literals.

Environment Context (from incident)
Linux host (Ubuntu)
Node 24.x
OpenClaw updated/reinstalled during incident
PM2-managed long-running trading process
Discord-driven operations, autonomous rollout requirements

Why this matters
This is not just a UX issue — it can break the control plane for autonomous agents at exactly the moment high reliability is required (deploy/recovery/live ops). Fixing path-to-regex handling and adding regression coverage should prevent recurrence.

What I found
From installed bundle wiring:

dist/exec-approvals-allowlist-BGAvVS2f.js calls matchAllowlist(...) (imported from model-selection-DxE_R9Al.js).
dist/index.js imports escapeRegExp from utils-BKDT474X.js.
Error shape strongly indicates raw executable path is being fed into new RegExp(...) unescaped.

So the likely bug is in/around allowlist command matching (probably matchAllowlist path/glob handling).

Proposed fix (include this in GitHub issue)
Patch intent: ensure any literal path/binary string is escaped before regex construction.
// helper (shared util)
function escapeRegExpLiteral(input: string): string {
return input.replace(/[.*+?^${}()|[]\]/g, "\$&");
}

Then replace any unsafe pattern creation like:

new RegExp(^${candidate}$, "i")

with:

ts
new RegExp(^${escapeRegExpLiteral(candidate)}$, "i")

And if wildcards/globs are supported, do escaped literal + controlled wildcard transform:

function wildcardToRegex(pattern: string): RegExp {
const escaped = escapeRegExpLiteral(pattern)
.replace(/\*/g, ".*")
.replace(/\?/g, ".");
return new RegExp(^${escaped}$, "i");
}

Candidate files/functions to patch
src/infra/exec-approvals-allowlist.ts
src/config/... or wherever matchAllowlist is implemented (compiled into model-selection-*.js)

(Compiled bundle evidence: evaluateExecAllowlist -> matchAllowlist path.)

Regression tests to add
literal executable path with plus signs:
/usr/bin/g++
/usr/bin/clang++
literal path with regex metacharacters:
/opt/tools/(custom)/bin/node
wildcard allowlist still works:
/usr/bin/*
no uncaught regex exceptions during policy evaluation.

Steps to reproduce

Install/update OpenClaw on Linux (Node 24+).
Ensure exec approval/allowlist path is active (default gateway config is sufficient).
Trigger any tool/CLI command execution through OpenClaw runtime (agent exec path).
During command resolution, include a binary path containing + (e.g. /usr/bin/g++) in matching/validation path (allowlist/safe-bin/policy evaluation).
Observe command runner failure with:Invalid regular expression: /^/usr/bin/g++$/i: Nothing to repeat

Expected behavior

Expected behavior
Command runner treats executable paths as literals during matching.
Paths containing regex metacharacters (+, ., (, ), [, ], {, }, ?, |) do not crash matcher compilation.
Exec path proceeds normally (or is rejected by policy with a normal validation message, not a runtime exception).
Agent command execution remains available after updates/restarts.

Actual behavior

Any command execution through the OpenClaw exec/runtime path can fail immediately with:Invalid regular expression: /^/usr/bin/g++$/i: Nothing to repeat
The failure appears during command policy/allowlist matching and throws before normal execution/validation flow.
Agent-side exec bridge becomes unusable (hard failure on each attempt), even when host shell commands may still work manually.
Operationally, this blocks autonomous recovery actions (process restart, migrations, health checks) and can leave systems in partial state until manual intervention.

OpenClaw version

2026.3.1 (and a couple previous)

Operating system

Ubuntu 24.04

Install method

npm global

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response