Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

tools.exec.timeoutSec is documented as the default timeout for the exec tool, but it is not applied when an exec call uses yieldMs or background without an explicit timeout parameter. Foreground exec correctly uses the configured default (e.g. 30s), while auto-backgrounded exec silently disables the default timeout, allowing commands to run indefinitely.

Steps to reproduce

1. Configure tools.exec.timeoutSec: 30 in ~/.openclaw/openclaw.json
2. Verify with openclaw config get tools.exec.timeoutSec (returns 30)
3. Run a foreground exec with a 35s sleep command (no explicit timeout) — process is killed at ~30s via SIGTERM(correct)
4. Run the same command with yieldMs: 1000 (no explicit timeout) — process completes past 30s (bug: default timeout not applied)
5. Run the same command with yieldMs: 1000 and timeout: 50 — per-call timeout works correctly

Test command used:

  {"tool": "exec", "command": "python3 - <<'PY'\nimport time\nprint('start', flush=True)\ntime.sleep(35)\nprint('end',flush=True)\nPY"}

Expected behavior

tools.exec.timeoutSec should remain the default timeout for all exec modes (foreground, yieldMs, background) unless explicitly overridden by a per-call timeout parameter. In the foreground path this works correctly — a 35s command is killed at ~30s when timeoutSec=30.

Actual behavior

When exec is called with yieldMs or background and no explicit timeout, the configured tools.exec.timeoutSec default is silently bypassed. The effective timeout becomes null, allowing the command to run indefinitely.

Root cause in bash-tools-CEAaYnEc.js:

const effectiveTimeout = allowBackground && explicitTimeoutSec === null && (backgroundRequested || yieldRequested) ? null : explicitTimeoutSec ?? defaultTimeoutSec;

OpenClaw version

2026.4.14

Operating system

N/A (not specified in report)

Install method

N/A (not specified in report)

Model

N/A (not model-specific bug)

Provider / routing chain

N/A (not provider-specific bug)

Additional provider/model setup details

This bug is not provider or model specific. It affects the exec tool timeout resolution logic in the OpenClaw runtime itself. The config is correctly loaded and passed to createExecTool(defaults), but the effective timeout computation bypasses it on the auto-background path.

Logs, screenshots, and evidence

- Config verification: `openclaw config get tools.exec.timeoutSec` returns 30
- Foreground exec: 35s sleep killed at ~30s (SIGTERM) — correct
- yieldMs exec: 35s sleep completes successfully — bug
- Explicit timeout with yieldMs: works correctly
- Source analysis: bash-tools-CEAaYnEc.js effectiveTimeout logic confirmed
- Related issues: #60151 (exec timeout vs agent run timeout), #44603 (tools.exec global defaults vs per-call params)

Impact and severity

1. Affected users / systems / channels
The system running the OpenClaw AI assistant, and any processes or services relying on its tool execution capabilities.

2. Severity – Disrupts workflow
Frequency – Special case (runaway AI tool call), In my VPS full disk grep search without stopping.

3. Consequences

• Memory spike (up to 2.9 GB), potentially slowing down system performance or triggering OOM killer.
• 8 zombie processes created, consuming process table entries and affecting system stability.
• If this recurs, it may lead to repeated resource exhaustion or hung tasks.

Additional context
Cleaned up residual zombie processes — found 8 stuck child processes doing a full-disk grep search (looks like a runaway AI tool call). All were killed, memory dropped from the 2.9 GB peak.

Additional information

By the way, this problem was discovered, tested and raised by OpenClaw itself.