openclaw - 💡(How to fix) Fix [Bug]: exec commands intermittently SIGKILL on macOS with no diagnostic cause [1 participants]

Summary

Agent/exec commands intermittently fail with a hard SIGKILL and no actionable diagnostic payload. From the user-facing side this surfaces as:

That command failed: the process was forcibly terminated with SIGKILL. No stdout/stderr details were included, so I can’t tell from this payload whether it was killed for timeout, memory, manual stop, or another supervisor reason.

This has happened repeatedly enough that it feels like a product bug rather than a one-off command failure.

Environment

• OpenClaw: 2026.4.24 (cbcfdf6)
• OS: macOS / Darwin 25.3.0 arm64
• Node: v25.9.0
• Runtime: main Telegram direct agent session, model openai-codex/gpt-5.5
• Gateway running locally via openclaw-gateway

Observed evidence from one incident

A broad diagnostic/search command over OpenClaw state/logs was killed with signal 9 while trying to investigate earlier async command failures. The failure produced no useful stdout/stderr explaining whether it was:

• supervisor timeout
• macOS memory pressure / OOM-style kill
• process tree cleanup
• manual cancellation
• gateway/session-lane interruption
• some other OpenClaw runner policy

At the time, bounded diagnostics showed:

• ~/.openclaw: ~15 GB
• /tmp/openclaw: ~45 MB
• ~/.openclaw/lcm.db: ~266 MB
• ~/.openclaw/logs/gateway.err.log: ~63 MB
• openclaw-gateway: ~2.4 GB RSS in ps
• background context-engine turn maintenance was active/deferred around the same time

The broad scan itself being SIGKILL'd makes the issue hard to self-diagnose, because the obvious next step (search logs/state) can reproduce the failure.

Expected behavior

When an exec/process is killed with SIGKILL, OpenClaw should surface enough metadata to distinguish likely causes, for example:

• command runtime before kill
• timeout limit, if any
• whether OpenClaw supervisor initiated the kill
• whether the process was killed during session interruption/cancellation
• peak/last-known RSS if tracked
• stdout/stderr tail captured before kill
• process tree / child count if relevant
• a pointer to the exact gateway log span or run id

It would also help if broad scans over known-large OpenClaw state/log directories were warned about or guarded with safer defaults/truncation.

Actual behavior

The user/agent only sees a generic SIGKILL message with no stdout/stderr or cause. The agent then has to guess between timeout, memory pressure, supervisor cancellation, etc. That leads to poor RCA and repeated expensive diagnostic attempts.

Repro shape

I do not have a minimal deterministic repro yet, but the recurring pattern is:

1. In an active main agent session, run a broad diagnostic command over OpenClaw state/logs, e.g. recursive grep/find across ~/.openclaw and /tmp/openclaw.
2. The command is managed by the exec/process tool.
3. Under a large local state directory and active gateway/context-maintenance load, the command is sometimes hard-killed.
4. The surfaced result contains only SIGKILL and no diagnostic cause.

A representative class of risky command:

grep -R "SIGKILL\|signal 9\|forcibly terminated\|killed" -n /tmp/openclaw ~/.openclaw 2>/dev/null | tail -200

Related issues

Possibly related but not identical:

• #69242 — Linux broad find/grep discovery commands SIGKILL without OOM evidence
• #66399 — process supervisor signal escalation / drain timeout
• #71710 — hung process chains exhausting RAM/swap

This report is specifically for recurring macOS agent/exec SIGKILLs with insufficient user-facing diagnostics, especially when OpenClaw state/log directories are large.

Suggested fixes

• Add structured kill metadata to exec/process results.
• Preserve and surface stdout/stderr tail on SIGKILL.
• Log whether the supervisor or OS initiated termination when knowable.
• Add run ids / log pointers to failed exec results.
• Consider guardrails for recursive scans over large OpenClaw state directories.