Codex dynamic-tool RPC timeout (30s hardcoded) breaks session_status and other enumeration-heavy MCP tools

Summary

CODEX_DYNAMIC_TOOL_TIMEOUT_MS and CODEX_SIDE_DYNAMIC_TOOL_TIMEOUT_MS are both hardcoded to 3e4 (30 seconds) with no config-surface override. Codex-runtime agents calling MCP tools that enumerate sessions (notably session_status sessionKey=current) hit this cap on gateways with bloated sessions, producing:

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

This is particularly load-bearing because session_status is the canonical introspection mechanism for agents to answer "what model am I running on?" — when it times out, agents fall back to reading injected runtime context (e.g. the active-memory plugin's flush model identity, currently openrouter/google/gemini-2.5-flash), which produces misreports.

Environment

• OpenClaw: 2026.5.22 (a374c3a) (current latest on npm)
• Install location: /opt/homebrew/lib/node_modules/openclaw/
• Affected agents: any agent on the openai-codex runtime. Agents on claude-cli runtime do not hit this cap.

Source locations

• dist/run-attempt-yn2wZ3Zh.js:4296 — const CODEX_DYNAMIC_TOOL_TIMEOUT_MS = 3e4;
• dist/side-question-CmOO0OyY.js:25 — const CODEX_SIDE_DYNAMIC_TOOL_TIMEOUT_MS = 3e4;
• Both constants are hardcoded; only per-call timeoutMs arguments can override (and only some tool schemas expose that argument — session_status does not).

Symptom (real-world example)

In our fleet, a Builder agent (running on openai-codex/gpt-5.5) was asked "what model are you on?" via Discord. Builder attempted to query mcp__openclaw__session_status({"sessionKey":"current"}) twice; both calls timed out after 30000ms. Builder then fell back to reading injected runtime context, which contained the active-memory plugin's flush-model identity (gemini-2.5-flash), and reported that instead — a wrong answer that produced operator confusion.

Builder's diagnostic, verbatim:

So my correction is: I should not have answered openrouter/google/gemini-2.5-flash earlier. That came from injected runtime context about the memory plugin/model identity, not the actual Builder Codex session. The live session evidence points to OpenAI/Codex, with local config intending gpt-5.5, but session_status is currently failing before it can provide the final exact confirmation.

Why 30s is too short

session_status enumerates sessions across all agent stores. Our gateway currently has 9 stores and 90 active sessions (down from 115 after a cleanup). Enumerating a primary session at 999% context (~1.6M tokens cached) can plausibly take >30s through the Codex dynamic-tool RPC. There is no way for the caller to know in advance whether the call will exceed 30s — and once it does, the operation is unrecoverable from the agent's perspective.

Comparable per-tool defaults in the same file are already longer:

• CODEX_DYNAMIC_IMAGE_GENERATION_TOOL_TIMEOUT_MS = 12e4 (120s)
• CODEX_DYNAMIC_IMAGE_TOOL_TIMEOUT_MS = 6e4 (60s)
• CODEX_DYNAMIC_MESSAGE_TOOL_TIMEOUT_MS = 12e4 (120s)

So 30s for all other tools (including session_status and most enumeration-heavy ones) is an outlier.

Requested fixes (ranked)

1. Raise the default — change both constants from 3e4 to a value that better matches the rest of the family (e.g. 9e4 / 90s). Single-line edits in both files. We applied this locally and confirmed Builder's introspection path works again.
2. Expose a config-surface override — tools.codex.dynamicToolTimeoutMs (or similar) so operators can tune without patching dist/. Useful for clusters with even bigger session loads.
3. Expose timeoutMs on session_status's MCP tool schema so callers can opt into a longer timeout per call. Less invasive than (1) but requires every caller to know to ask.

Any one of these would unblock the legitimate use case. We'd recommend (1) for the default + (2) for the override path.

Related v5.22-vintage upstream issue

Already filed at #86687 (v5.22 group-chat over-suppression + sticky image re-attachment). This is the third regression we've root-caused in the v5.22 release window. Different code paths, but cumulative effect on fleet behavior is significant.

Architectural follow-up (separate, longer-term)

The active-memory plugin's flush systemPrompt (dist/extensions/active-memory/index.js:576) injects the flush model's identity into the host agent's runtime context without namespacing. When session_status is unavailable, agents can mistake the flush model for their own session model. Worth disambiguating the flush prompt (e.g. "the memory consolidator runs on model X") — but the load-bearing fix is the timeout (this issue), since with a working session_status agents would never need to inspect runtime context for self-identification.

Happy to test a pre-release patch or beta build.