openclaw - 💡(How to fix) Fix image_generate ignores timeoutMs in Codex dynamic tool bridge and times out at 30000ms while generation still completes [1 comments, 2 participants]

Summary

image_generate appears to ignore the configured/per-call timeout budget when it is invoked through the Codex dynamic tool bridge.

Even with agents.defaults.imageGenerationModel.timeoutMs = 300000 and a per-call timeoutMs: 300000, OpenClaw returns a dynamic tool timeout after 30000ms:

OpenClaw dynamic tool call timed out after 30000ms while running tool image_generate.

Gateway logs show:

[agent/embedded] codex dynamic tool timeout: tool=image_generate toolTimeoutMs=30000; per-tool-call watchdog, not session idle

The image generation itself still completes in the background and writes the output file to the media store. So the user-visible turn fails even though the requested image is actually generated.

This looks different from #71705. That issue is about slow provider-side image generation defaults. Here, the configured/per-call timeout is already 300000ms, but the Codex dynamic tool bridge still uses 30000ms.

Environment

• OpenClaw: 2026.5.7 (eeef486)
• Install method: npm global
• OS: macOS / arm64
• Node: Node 26
• Runtime path: OpenClaw Codex harness / embedded agent
• Model: openai/gpt-5.5
• Image generation model: openai/gpt-image-2
• Channel used for repro: chat channel

Relevant config

{
  "agents": {
    "defaults": {
      "imageGenerationModel": {
        "primary": "openai/gpt-image-2",
        "fallbacks": [],
        "timeoutMs": 300000
      }
    }
  }
}

openclaw config validate passes.

Reproduction

Invoke image_generate from a Codex-backed OpenClaw session with an explicit timeout:

{
  "prompt": "Use case: productivity-visual\nAsset type: OpenClaw image_generate timeout smoke test artifact\nPrimary request: Create a simple clean diagnostic image that clearly says \"IMAGE TOOL SMOKE\" and includes a small green check mark icon on a plain light background.\nScene/backdrop: Minimal flat light gray background, no texture.\nSubject: Centered text and a simple check mark, sharp and readable.\nStyle: clean utility graphic, not photorealistic.\nConstraints: no extra text, no watermark.",
  "size": "1024x1024",
  "quality": "low",
  "count": 1,
  "filename": "openclaw-image-generate-smoke.png",
  "timeoutMs": 300000
}

Expected behavior

The Codex dynamic tool bridge should honor the same timeout budget as documented for image_generate, bounded by the documented 600000ms maximum.

In this case the dynamic tool budget should be 300000ms, not 30000ms.

If the provider request eventually succeeds within that budget, the tool result should return the generated media path and the channel should deliver the generated image normally.

Actual behavior

OpenClaw returns a dynamic tool failure after 30000ms:

OpenClaw dynamic tool call timed out after 30000ms while running tool image_generate.

Gateway log:

2026-05-13T16:25:02.942+09:00 [agent/embedded] codex dynamic tool timeout: tool=image_generate toolTimeoutMs=30000; per-tool-call watchdog, not session idle

Despite that failure, the generated image is later present in the media store:

~/.openclaw/media/tool-image-generation/openclaw-image-generate-smoke---<uuid>.png

File inspection:

PNG image data, 1024 x 1024, 8-bit/color RGB, non-interlaced
703K

Documentation mismatch

The current docs say:

• image_generate per-call timeoutMs overrides the configured default and is capped at 600000ms.
• agents.defaults.imageGenerationModel.timeoutMs should be used for slow image backends.
• Codex dynamic-tool calls honor the same timeout budget, bounded by OpenClaw's 600000ms dynamic-tool bridge maximum.

Observed behavior in 2026.5.7 does not match that: the bridge still uses 30000ms.

Impact

This makes long-running image generation look failed or silent in chat surfaces, even when generation succeeds. In Slack/Discord workflows the user may see a timeout/failure while the image has already been generated in ~/.openclaw/media/tool-image-generation.

It also causes repeated retries and confusion because the agent may try again even though a valid generated file exists.

Suggested fix

At minimum, ensure the Codex dynamic tool bridge computes the per-tool watchdog for image_generate from:

1. explicit tool-call timeoutMs
2. agents.defaults.imageGenerationModel.timeoutMs
3. the normal default

and caps that value at the documented 600000ms maximum.

Longer term, image_generate may need the same background-task pattern as video_generate / music_generate, so the tool can acknowledge quickly and deliver completion/failure asynchronously.