rtk-ai/rtk

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

Open

#1388 opened on Apr 18, 2026

View on GitHub
 (1 comment) (0 reactions) (0 assignees)Rust (48,085 stars) (2,914 forks)batch import
bugeffort-smallgood first issue

Description

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

Contributor guide