openclaw - 💡(How to fix) Fix Codex dynamic tool timeout is not configurable for plugin runtime tools [1 comments, 2 participants]

Summary

The Codex dynamic-tool watchdog enforces a 30s default per-tool-call timeout (CODEX_DYNAMIC_TOOL_TIMEOUT_MS = 30000 in the 2026.5.18 bundle). #79810 extended the cap to 600s for tools that can declare a higher per-call timeoutMs, but:

1. The public plugin SDK (defineToolPlugin) has no per-tool timeoutMs field in ToolPluginToolDefinitionBase or the generated ToolPluginStaticToolMetadata.
2. The only tools that get a configurable timeout are image_generate (via agents.defaults.imageGenerationModel.timeoutMs) and image (via tools.media.image.timeoutSeconds), both special-cased in the bridge.
3. Plugin runtime tools registered via api.registerTool(...) or defineToolPlugin therefore cannot escape the 30s default, even when their internal execution profile is known to be longer.

This is a structural gap on the OpenClaw side, not a plugin bug.

Repro

Plugin: @martian-engineering/[email protected] (peerDep openclaw >=2026.5.12).

The lcm_expand_query tool documents and defaults to a delegationTimeoutMs: 120000 (120s) internal budget per the package's docs/configuration.md. On 2026.5.18, the OpenClaw outer wrapper kills the call at 30s while lossless's internal delegation continues in the background. A follow-up call ~90s after the timeout sometimes returns the answer (the in-flight delegation completes), but the original parent never sees it. Concurrent expansions are blocked with EXPANSION_CONCURRENCY_BLOCKED while the abandoned delegation is still running.

Literal gateway log line (2026.5.18, conv with ~272k assembled tokens):

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

The runtime identifies the path itself.

Evidence

Installed 2026.5.18 binary constants (from dist/run-attempt-*.js and dist/client-*.js):

• CODEX_DYNAMIC_TOOL_TIMEOUT_MS = 3e4 (30s) — default
• CODEX_DYNAMIC_TOOL_MAX_TIMEOUT_MS = 6e5 (600s) — max cap from #79810
• CODEX_DYNAMIC_TOOL_SERVER_REQUEST_TIMEOUT_MS = 6e5 — server-side fallback, also aligned to 600s

Plugin SDK type definitions (dist/plugin-sdk/src/plugin-sdk/tool-plugin.d.ts):

type ToolPluginToolDefinitionBase<TParamsSchema extends TSchema> = {
    name: string;
    label?: string;
    description: string;
    parameters: TParamsSchema;
    optional?: boolean;
};

export type ToolPluginStaticToolMetadata = {
    name: string;
    label: string;
    description: string;
    parameters: JsonSchemaObject;
    optional?: boolean;
};

No timeout field exposed on either the definition or the generated manifest metadata.

#79810 fix scope (per closing comment by @steipete):

• image_generate uses agents.defaults.imageGenerationModel.timeoutMs when no per-call timeout is supplied.
• The media-understanding image tool uses tools.media.image.timeoutSeconds or its 60s media default

Plugin runtime tools are not in the enumerated list, and no documented config path exists for them.

Expected

A plugin runtime tool with a known longer execution profile should be able to either:

1. Declare per-tool timeoutMs in the SDK definition / generated manifest, e.g. extending ToolPluginToolDefinitionBase with an optional timeoutMs?: number honored by the Codex dynamic-tool bridge up to CODEX_DYNAMIC_TOOL_MAX_TIMEOUT_MS, or
2. Opt into a longer bridge timeout via documented config, analogous to agents.defaults.imageGenerationModel.timeoutMs for image_generate — for example a plugins.entries.<id>.tools.<toolName>.timeoutMs path.

Without either, plugins cannot use OpenClaw's existing 600s cap, and tools with known longer budgets are forced to die at 30s while their internal work is wasted in the background.

Environment

• OpenClaw: 2026.5.18 (50a2481)
• Plugin: @martian-engineering/[email protected]
• macOS, Node 22.19, Codex provider via OpenAI ChatGPT OAuth (openai-codex/gpt-5.5)