feat(config): add agents.defaults.subagents.timeoutSeconds#109
Merged
dgarson merged 1 commit intodgarson/forkfrom Feb 23, 2026
Merged
feat(config): add agents.defaults.subagents.timeoutSeconds#109dgarson merged 1 commit intodgarson/forkfrom
dgarson merged 1 commit intodgarson/forkfrom
Conversation
Adds a default timeout for spawned sub-agents, configurable via agents.defaults.subagents.timeoutSeconds in openclaw.json. Previously, sub-agents with no explicit runTimeoutSeconds in the sessions_spawn call defaulted to unlimited (0 = NO_TIMEOUT_MS in resolveAgentTimeoutMs). This meant the global agents.defaults.timeoutSeconds had no effect on sub-agents — only top-level sessions. Changes: - zod-schema.agent-defaults.ts: add timeoutSeconds to the subagents .strict() schema object so the field is accepted and validated - types.agent-defaults.ts: add timeoutSeconds?: number to the AgentDefaultsConfig.subagents interface - subagent-registry.ts (registerSubagentRun): fall back to cfg.agents.defaults.subagents.timeoutSeconds when no per-call runTimeoutSeconds is provided, before defaulting to 0 (unlimited) - subagent-registry.ts (replaceSubagentRunAfterSteer): same fallback so resumed/steered sub-agents also respect the default Explicit per-call runTimeoutSeconds=0 still means unlimited (no behavior change for existing callers). If the config field is unset, behavior is identical to before.
dgarson
added a commit
that referenced
this pull request
Feb 24, 2026
Adds a default timeout for spawned sub-agents, configurable via agents.defaults.subagents.timeoutSeconds in openclaw.json. Previously, sub-agents with no explicit runTimeoutSeconds in the sessions_spawn call defaulted to unlimited (0 = NO_TIMEOUT_MS in resolveAgentTimeoutMs). This meant the global agents.defaults.timeoutSeconds had no effect on sub-agents — only top-level sessions. Changes: - zod-schema.agent-defaults.ts: add timeoutSeconds to the subagents .strict() schema object so the field is accepted and validated - types.agent-defaults.ts: add timeoutSeconds?: number to the AgentDefaultsConfig.subagents interface - subagent-registry.ts (registerSubagentRun): fall back to cfg.agents.defaults.subagents.timeoutSeconds when no per-call runTimeoutSeconds is provided, before defaulting to 0 (unlimited) - subagent-registry.ts (replaceSubagentRunAfterSteer): same fallback so resumed/steered sub-agents also respect the default Explicit per-call runTimeoutSeconds=0 still means unlimited (no behavior change for existing callers). If the config field is unset, behavior is identical to before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Sub-agents spawned without an explicit
runTimeoutSecondsin thesessions_spawncall defaulted to unlimited timeout. The existingagents.defaults.timeoutSecondsfield had no effect on sub-agents — only on top-level agent sessions.This caused last night's fleet incident: Barry's deterministic replay workstream and Tim's heartbeat workers ran until the gateway killed them (or didn't), rather than timing out cleanly.
Solution
Adds
agents.defaults.subagents.timeoutSeconds— a configurable default timeout that applies to all spawned sub-agents when no per-call override is provided.{ "agents": { "defaults": { "subagents": { "timeoutSeconds": 600 } } } }Changes (3 files, 14 insertions, 2 deletions)
src/config/zod-schema.agent-defaults.ts— addstimeoutSecondsto thesubagentsobject schema (required since the schema uses.strict())src/config/types.agent-defaults.ts— addstimeoutSeconds?: numberto theAgentDefaultsConfig.subagentsinterfacesrc/agents/subagent-registry.ts— two one-line changes:registerSubagentRun: falls back tocfg.agents.defaults.subagents.timeoutSecondsbefore0(unlimited)replaceSubagentRunAfterSteer: same fallback so resumed/steered sub-agents also respect the defaultBehavior
runTimeoutSecondsexplicitly passedrunTimeoutSecondsnot passed, config unsetrunTimeoutSecondsnot passed, config set to 600No breaking changes. Existing callers passing
runTimeoutSeconds: 0retain unlimited timeout.