bug(openclaw): plugin discards rewrite stdout on non-zero exit

[jhenderiks]

Summary

The OpenClaw plugin currently discards any successful rtk rewrite output if the child process exits non-zero.

The plugin uses execSync(...), so Node throws on any non-zero exit code and the plugin returns null. That means if rtk rewrite ever emits a valid rewritten command on stdout while exiting non-zero, the rewrite is silently lost.

Current plugin logic

function tryRewrite(command: string): string | null {
  try {
    const result = execSync(`rtk rewrite ${JSON.stringify(command)}`, {
      encoding: "utf-8",
      timeout: 2000,
    }).trim();
    return result && result !== command ? result : null;
  } catch {
    return null;
  }
}

Why this is a bug

The plugin assumes that a useful rewrite can only come back on exit 0.

That is brittle. If RTK emits a rewritten command on stdout together with a non-zero status for any classification or environment-specific reason, the OpenClaw plugin will drop the rewrite entirely.

Expected behavior

If rtk rewrite emits a rewritten command on stdout, the OpenClaw plugin should preserve and use that rewrite even when the subprocess exits non-zero.

Suggested fix direction

Handle non-zero exits without discarding stdout. For example:

• inspect error.stdout in the catch, or
• switch to a subprocess API that always exposes stdout/status together

Notes

I originally observed a case where rtk rewrite returned rewritten stdout with a non-zero exit, but I have not re-confirmed that exact exit behavior on every environment / version combination.

So the most precise framing is:

• this is definitely a robustness hole in the OpenClaw plugin
• whether it is a currently reproducible regression on latest RTK may be environment/version dependent

[pszymkowiak]

[w] wshm · Automated triage by AI

🔍 Automated Triage

🐛 Category	bug
🟢 Priority	low
🎯 Confidence	72%

Summary

OpenClaw plugin silently discards rtk rewrite stdout on non-zero exit; robustness issue with unclear real-world impact. PR #1389 already in progress.

This looks like a simple fix. Only repo maintainers can trigger auto-fix.

---

Triaged automatically by wshm · This is an automated analysis, not a human review.