Cleaner Script Shutdowns: OpenClaw 2026.2.17 Now Sends SIGTERM Before SIGKILL

If you've ever run long-running scripts through your OpenClaw agent, you know the frustration: a timeout hits, your process gets killed instantly, and any cleanup code never runs. Temp files left behind. Database connections abandoned. Partial writes corrupted.

OpenClaw 2026.2.17 changes this with a simple but impactful fix: process trees are now gracefully terminated with SIGTERM before SIGKILL.

What Changed

Previously, when OpenClaw needed to stop a running process (timeout, abort, or cleanup), it would send SIGKILL immediately. SIGKILL is the nuclear option—the process has no chance to respond, no cleanup handlers run, no graceful exit.

Now, OpenClaw sends SIGTERM first, giving your scripts time to catch the signal and shut down properly. If the process doesn't exit within a grace period, then SIGKILL follows.

Why This Matters

This isn't just a nice-to-have—it enables a whole class of reliable automation:

Database scripts can commit or rollback transactions instead of leaving them hanging.

File processing can flush buffers and close handles properly.

API integrations can send completion signals or cleanup webhooks.

Long-running builds can cache intermediate state for faster restarts.

Making Your Scripts Signal-Aware

To take advantage of this, your scripts need to handle SIGTERM:

import signal
import sys

def cleanup(signum, frame):
    print("Caught SIGTERM, cleaning up...")
    # Close connections, flush files, etc.
    sys.exit(0)

signal.signal(signal.SIGTERM, cleanup)

In Node.js:

process.on('SIGTERM', () => {
  console.log('Caught SIGTERM, shutting down gracefully...');
  // Cleanup logic here
  process.exit(0);
});

In Bash:

cleanup() {
  echo "Cleaning up..."
  # Your cleanup commands
  exit 0
}
trap cleanup SIGTERM

The Takeaway

This is one of those small changes that makes OpenClaw feel more production-ready. Your agents can now run scripts that handle interruption gracefully, just like any well-behaved Unix process should.

Thanks to @sauerdaniel for contributing this fix in PR #18626.

Reference: GitHub PR #18626