Bug type

Regression (worked before, now fails)

Summary

When spawning a subagent via sessions_spawn without passing an explicit runTimeoutSeconds, the timeout resolves to 0, which the timeout resolver interprets as "no timeout" (infinite). The configured default at agents.defaults.subagents.runTimeoutSeconds is never applied. Subagent runs have no effective timeout unless the caller explicitly passes one.

Steps to reproduce

1. Set agents.defaults.subagents.runTimeoutSeconds: 600 (10 min) in config
2. Spawn a subagent: sessions_spawn({ agentId: "my-agent", task: "..." }) — without passing runTimeoutSeconds
3. Observe: the subagent runs indefinitely past 10 minutes — never killed by timeout
4. Expected: subagent should be killed after 600 seconds (10 min)

Expected behavior

Subagent should be killed after the configured agents.defaults.subagents.runTimeoutSeconds when no explicit timeout is passed in the spawn call.

Actual behavior

Subagent runs indefinitely. The configured default is never applied because the fallback chain resolves to 0, and the timeout resolver treats 0 as "disable timeout."

OpenClaw version

2026.3.24

Operating system

Ubuntu 24.04 LTS (Linux 6.18.7 x64)

Install method

npm global

Model

anthropic/claude-sonnet-4-6

Provider / routing chain

openclaw -> anthropic (direct)

Additional provider/model setup details

Bug is in subagent timeout resolution, not model-specific.

Logs, screenshots, and evidence

Tested with runTimeoutSeconds: 600 (10 min) configured. Spawned subagent without explicit timeout. Subagent ran 15+ minutes before being manually killed.

Root cause — three-step resolution chain:

Step 1 — Spawn registration (pi-embedded-BaSvmUpW.js:98937):

const runTimeoutSeconds = params.runTimeoutSeconds ?? source.runTimeoutSeconds ?? 0;

When not passed, resolves to 0.

Step 2 — Wait timeout resolution (pi-embedded-BaSvmUpW.js:98613-98617):

function resolveSubagentWaitTimeoutMs(cfg, runTimeoutSeconds) {
    return resolveAgentTimeoutMs({
        cfg,
        overrideSeconds: runTimeoutSeconds ?? 0
    });
}

Passes overrideSeconds: 0.

Step 3 — Timeout resolver (manager-BFi-xqLj.js:18-37):

const overrideSeconds = normalizeNumber(opts.overrideSeconds);
if (overrideSeconds !== void 0) {
    if (overrideSeconds === 0) return NO_TIMEOUT_MS;  // ← treats 0 as "disable"
    if (overrideSeconds < 0) return defaultMs;
    return clampTimeoutMs(overrideSeconds * 1e3);
}
return defaultMs;  // ← configured default, never reached

The resolver correctly uses the configured default when overrideSeconds is undefined, but Step 1 always provides 0 as fallback — so undefined never reaches the resolver.

Impact and severity

Medium — All subagent runs spawned without explicit runTimeoutSeconds have no timeout. Stalled/zombie subagents consume resources indefinitely until manually killed. The configured agents.defaults.subagents.runTimeoutSeconds setting has no effect on spawn-based subagents.

Additional information

Suggested fix — change the fallback in Step 1 from 0 to undefined:

// Before:
const runTimeoutSeconds = params.runTimeoutSeconds ?? source.runTimeoutSeconds ?? 0;

// After:
const runTimeoutSeconds = params.runTimeoutSeconds ?? source.runTimeoutSeconds ?? undefined;

This way overrideSeconds reaches the resolver as undefined, correctly falling through to resolveAgentTimeoutSeconds(cfg) (the configured default). An explicit runTimeoutSeconds: 0 from the caller would still disable the timeout as intended.

Workaround: Explicitly pass runTimeoutSeconds in every sessions_spawn call.