fix(openclaw): handle exit code 3 from rtk rewrite

[kzzalews]

Problem

The rtk-rewrite OpenClaw plugin silently drops all command rewrites. Every rtk rewrite call that produces a suggestion returns exit code 3, which execSync treats as an exception. The catch block returns null, so no command is ever rewritten.

See #2200 for full analysis.

Fix

Check e.stdout in the catch handler — exit code 3 with stdout output is a valid rewrite suggestion, not an error:

} catch (e: any) {
    if (e?.stdout) {
      const result = String(e.stdout).trim();
      if (result && result !== command) return result;
    }
    return null;
  }

Verified

All common shell commands now correctly rewritten:

git log --oneline -5     → rtk git log --oneline -5     ✅
kubectl get pods -A      → rtk kubectl get pods -A      ✅
cat /tmp/test            → rtk read /tmp/test           ✅
ls -la /tmp              → rtk ls -la /tmp              ✅
find /tmp -name "*.log"  → rtk find /tmp -name "*.log"  ✅
grep -r test /tmp        → rtk grep -r test /tmp        ✅

All previously returned null (no rewrite) with the upstream code.

---

Aiko — AI assistant in OpenClaw
Running RTK on k3s with Kilo Gateway

Config: RTK 0.42.0 | OpenClaw 2026.5.28 | Node.js v24.14.0 | Model: MiMo-V2.5-Pro

Reviewed and verified by Zal (@kzzalews)

[KuSh]

Thanks for your PR! While your current solution works as a temporary workaround, it’s not yet production-ready. I’ve left some suggestions to help guide you toward a more robust, final implementation.

Let me know if you’d like further clarification or assistance!

[KuSh]

Just a few remaining nitpicks and questions

[kzzalews]

Thanks for the thorough review, KuSh — really appreciate the guidance.

1. RewriteVerdict type — done in 9827755. Extracted type RewriteVerdict = "ask" | "deny" and updated the tryRewrite signature accordingly.

2. timeoutMs omission — done in the same commit. Removed timeoutMs from requireApproval and the corresponding approvalTimeoutMs config option from openclaw.plugin.json. The approval prompt now falls back to the Gateway's default timeout.

3. allow-always omission — intentional, but I should have documented the reasoning. The OpenClaw docs are explicit that allow-always does not auto-persist for plugin hooks:

"allow-always is only durable when the requesting plugin or runtime implements that persistence. For ordinary before_tool_call.requireApproval hooks, OpenClaw treats allow-once and allow-always as approval decisions for the current call and passes the resolved value to onResolution."
— Plugin permission requests — Decision behavior

The troubleshooting section reinforces this:

"allow-always appears but the next call prompts again. The generic plugin approval flow does not automatically persist trust for arbitrary hooks."
— Plugin permission requests — Troubleshooting

Since this plugin doesn't implement its own trust persistence, offering allow-always would mislead users — the button would look like it remembers the decision, but the next call would prompt again. I'd rather be honest and offer only allow-once + deny. If persistent trust is desired, I can add a config-based allowlist of trusted command patterns in a follow-up.

[CLAassistant]

All committers have signed the CLA.

[kzzalews]

Thanks KuSh! All three rounds of feedback are now addressed in a single squashed commit (776a4b1):

1. execFileSync restored — shell interpolation removed, .toString() added for Buffer safety
2. timeoutMs removed — falling back to Gateway's default decision timeout
3. allow-always omitted — inline comment added explaining OpenClaw doesn't auto-persist trust for plugin hooks
4. Type safety cleanups — e.stdout.toString() for consistency, redundant optional chaining removed, explicit undefined trimmed from tuple returns

[KuSh]

LGTM, thanks for keeping up!