Summary
Allow users to configure the exec tool's timeout limit via openclaw.json, rather than being constrained by the embedded agent run timeout (default 600s).
Problem
When an exec command (e.g., a long-running build, download, or data processing task) takes longer than the embedded agent run timeout (600s), the entire agent turn is aborted — killing the exec process mid-execution. This is a frequent pain point for:
- Long-running downloads (e.g., large model files, datasets)
- Build/compile tasks
- Data processing pipelines
- Any shell command exceeding ~10 minutes
Current behavior
- Agent starts a turn → calls exec with
timeout: 600
- The exec tool itself defaults to
defaultTimeoutSec = 1800 (30 min)
- But the embedded agent run has its own timeout (600s) that kills the entire turn
- Result: exec process is SIGKILL'd even though exec tool would have allowed more time
Workarounds (all fragile)
- Use
background: true + yieldMs — but background processes still get killed when the agent turn times out
- Use
sessions_spawn to offload to sub-agents — adds complexity
- Manually set
timeoutSeconds: 0 on cron jobs — not applicable to interactive sessions
Proposed solution
Add a configurable tools.exec.timeoutSec field in openclaw.json:
{
"tools": {
"exec": {
"timeoutSec": 3600
}
}
}
Additionally, consider exposing the embedded agent run timeout as agents.defaults.runTimeoutSeconds so users can override the 600s default for long-running sessions.
Implementation notes
Based on code analysis:
defaultTimeoutSec is already configurable via tools.exec.timeoutSec (line 2948 in pi-embedded-bukGSgEe.js)
- The 600s limit comes from the embedded agent run timeout, not the exec tool itself
runTimeoutSeconds is already supported for sub-agents and cron agent turns
- The fix should allow
agents.defaults.runTimeoutSeconds to also apply to main session turns
Impact
- Affected: All users running long exec commands (>10 min)
- Severity: Medium — causes data loss and wasted API calls
- Frequency: Daily for users doing build/download/data tasks
- Backwards compatible: Yes — defaults remain unchanged
Related issues
Summary
Allow users to configure the exec tool's timeout limit via
openclaw.json, rather than being constrained by the embedded agent run timeout (default 600s).Problem
When an exec command (e.g., a long-running build, download, or data processing task) takes longer than the embedded agent run timeout (600s), the entire agent turn is aborted — killing the exec process mid-execution. This is a frequent pain point for:
Current behavior
timeout: 600defaultTimeoutSec = 1800(30 min)Workarounds (all fragile)
background: true+yieldMs— but background processes still get killed when the agent turn times outsessions_spawnto offload to sub-agents — adds complexitytimeoutSeconds: 0on cron jobs — not applicable to interactive sessionsProposed solution
Add a configurable
tools.exec.timeoutSecfield inopenclaw.json:{ "tools": { "exec": { "timeoutSec": 3600 } } }Additionally, consider exposing the embedded agent run timeout as
agents.defaults.runTimeoutSecondsso users can override the 600s default for long-running sessions.Implementation notes
Based on code analysis:
defaultTimeoutSecis already configurable viatools.exec.timeoutSec(line 2948 inpi-embedded-bukGSgEe.js)runTimeoutSecondsis already supported for sub-agents and cron agent turnsagents.defaults.runTimeoutSecondsto also apply to main session turnsImpact
Related issues