openclaw - 💡(How to fix) Fix [Feature] Expose codex turn-completion idle timeout as agent-profile config (60s default is too aggressive for gpt-5.5 extended reasoning)

Summary

CODEX_TURN_COMPLETION_IDLE_TIMEOUT_MS is hardcoded to 60 s in extensions/codex/src/app-server/run-attempt.ts. With reasoning-heavy models like openai-codex/gpt-5.5, the model can pause well beyond 60 s between tool calls during extended reasoning, and the watchdog kills runs that would otherwise have completed successfully. The resolver function accepts a programmatic options.turnCompletionIdleTimeoutMs override, but there is no agent-profile, gateway-config, or env-var path that wires through.

Hardcoded constants (v2026.5.18)

From dist/run-attempt-*.js:

const CODEX_TURN_COMPLETION_IDLE_TIMEOUT_MS            = 6e4;       // 60 s
const CODEX_TURN_ASSISTANT_COMPLETION_IDLE_TIMEOUT_MS  = 1e4;       // 10 s
const CODEX_TURN_TERMINAL_IDLE_TIMEOUT_MS              = 30 * 6e4;  // 30 min

The resolver:

function resolveCodexTurnCompletionIdleTimeoutMs(value) {
  if (value === void 0) return CODEX_TURN_COMPLETION_IDLE_TIMEOUT_MS;
  if (!Number.isFinite(value)) return CODEX_TURN_COMPLETION_IDLE_TIMEOUT_MS;
  return Math.max(1, Math.floor(value));
}

Reproducer — trajectory excerpt from a live run

Session a1f8949e-…, model openai-codex/gpt-5.5, single OpenAI Codex profile, MCP tools enabled.

16:38:59  +   0.0s  prompt.submitted
16:40:06  +  66.9s  tool.call        (first tool call — already past the 60 s threshold once)
16:40:06  +   0.1s  tool.result
16:49:27  + 561.0s  tool.call        ← 9 min 21 s of extended reasoning, no output
16:49:28  +   0.9s  tool.result
16:49:35  +   7.8s  tool.call
16:49:41  +   5.2s  tool.result
16:50:41  +  60.0s  turn.completion_idle_timeout   ← killed
16:50:41           session.ended

Two observations:

1. Tool execution is fast (106 ms, 926 ms, 5.2 s). The idle is the model thinking, not a hung tool, not a hung subprocess, not OpenAI being slow.
2. A 561 s pause earlier in the same run did not trigger the watchdog. Only the final pause did. So the watch is being re-armed by something — possibly the rawResponseItem path discussed in #82743 — but it still trips on the next quiet window, killing a turn that the model would otherwise have completed.

What the closed #82743 fix did and did not address

#82743 was about the 60 s turnCompletionIdleWatch being disarmed by a post-tool-call rawResponseItem/completed notification, leaving no safety net. That fix is about re-arming correctly. It does not address the value being too low for modern reasoning models, which is a separate concern: even a correctly armed 60 s watchdog will kill long extended-thinking pauses.

Trajectory event has a missing field

In the same run the recorded event shows timeoutMs: undefined (rendered as timeoutMs=None in our parser). Looking at the bundle:

trajectoryRecorder?.recordEvent("turn.completion_idle_timeout", {
  threadId, turnId, idleMs,
  timeoutMs: turnCompletionIdleTimeoutMs,
  lastActivityReason, ...lastActivityDetails
});

turnCompletionIdleTimeoutMs is in scope, so the missing field suggests the variable is shadowed or the override pathway sets it to undefined in one of the branches. Minor cosmetic bug but it makes the timeout invisible in postmortem trajectories.

Proposed fix

1. Add a per-agent-profile config field: agents.<name>.codex.turnCompletionIdleTimeoutMs (and the sibling assistantCompletion / terminal variants).
2. Plumb it into the options argument the resolver already accepts.
3. Recommend raising the default to 5–10 minutes for reasoning models, or expose it as a per-model default in the model catalog.
4. Always record timeoutMs in the turn.completion_idle_timeout trajectory event.