Client or integration
Codex App
Area
Tools / MCP / web search
Summary
On current dev (a228ed741, package 2.27.0), Grok-routed Codex App still rejects multi_agent_v1__wait_agent before the tool runs:
failed to parse function arguments: invalid type: floating point `120000.0`, expected u64
failed to parse function arguments: invalid type: floating point `60000.0`, expected u64
The model intended an integer millisecond budget. Codex's tool schema declares timeout_ms as a Rust u64. OpenCodex already has the #1611 integral-float repair (src/lib/tool-argument-integers.ts, wired in src/bridge.ts), but this call still arrives with a .0 and never executes.
Expected: an integral float in an integer-declared field is repaired to an integer, the wait runs, and a live subagent completion is returned. A timeout should still return timed_out: true with empty status only when no agent actually finished — that empty-status contract is not itself the bug.
Reproduction
- Route Codex App / Codex Desktop through OpenCodex with default provider xAI Grok (
xai/grok-4.6 in this session).
- Spawn a long-running subagent via
multi_agent_v1__spawn_agent.
- Call
multi_agent_v1__wait_agent with timeout_ms: 120000 (or 180000 / 60000). Grok serializes the field as 120000.0.
- Observe the function-call rejection above. The wait tool does not run. A later successful wait (when the argument is a real integer) can return a completed agent that was never stopped.
This session also showed a second, separate observation: wrapping wait_agent inside the code-mode exec isolate with a first-line // @exec: {"yield_time_ms": 180000} pragma still yielded the isolate at ~30s with empty output ("Script running with cell ID …") when the pragma was not the first line of the isolate source. That is a usage/host-tool issue, not this bug. The GitHub issue is only the timeout_ms float rejection.
Version
2.27.0 / dev a228ed7410f148a9462b4db2eee2b0e31d004d05
Operating system
macOS 27.0 (26A5378n)
Provider and model
xai / grok-4.6 (OpenCodex default provider; Codex App tool surface)
Logs or error output
failed to parse function arguments: invalid type: floating point `120000.0`, expected u64 at line 1 column 40
failed to parse function arguments: invalid type: floating point `60000.0`, expected u64 at line 1 column 39
Live wait that later succeeded with an integer timeout (agent was still running — not dead):
wait_agent({ targets: ["01a0266d-e77c-7402-a590-a1c4adb0c943", ...], timeout_ms: 15000 })
-> { "status": {}, "timed_out": true }
wait_agent({ targets: ["01a0266d-ec1b-74e2-a34a-2c38cd2a8cc9"], timeout_ms: 15000 })
-> { "status": { "01a0266d-ec1b-74e2-a34a-2c38cd2a8cc9": { "completed": "..." } }, "timed_out": false }
Screenshots and supporting files
N/A. Citations from this tree:
- Repair exists only when the declared schema type is
integer, not number: src/lib/tool-argument-integers.ts:49-53 (declaresInteger), 182-186 (no schema → no-op).
- Bridge applies that repair using
toolParameterSchemas.get(currentToolCall.name) / wire name: src/bridge.ts:623-629, 1654-1659.
- Schemas are keyed by
namespacedToolName(namespace, name) which for this tool is multi_agent_v1__wait_agent: src/server/responses/collaboration.ts:121-126, src/types/tools.ts:30-32.
- Cursor-advertised
yield_time_ms is still type: "number" (src/adapters/cursor/tool-definitions.ts:49), so even a looked-up schema would skip integer repair for that sibling field. wait_agent.timeout_ms is a Codex-native u64 and needs the integer path.
Likely remaining hole vs closed #1611: either the wait_agent schema is not in toolParameterSchemas under the name Grok emitted, or a type: "number" declaration prevents the integer rewrite. Both leave 120000.0 on the wire.
Redacted configuration
{
"defaultProvider": "xai",
"note": "local ocx on port 10100; no tokens included"
}
Checks
Client or integration
Codex App
Area
Tools / MCP / web search
Summary
On current
dev(a228ed741, package2.27.0), Grok-routed Codex App still rejectsmulti_agent_v1__wait_agentbefore the tool runs:The model intended an integer millisecond budget. Codex's tool schema declares
timeout_msas a Rustu64. OpenCodex already has the #1611 integral-float repair (src/lib/tool-argument-integers.ts, wired insrc/bridge.ts), but this call still arrives with a.0and never executes.Expected: an integral float in an integer-declared field is repaired to an integer, the wait runs, and a live subagent completion is returned. A timeout should still return
timed_out: truewith emptystatusonly when no agent actually finished — that empty-status contract is not itself the bug.Reproduction
xai/grok-4.6in this session).multi_agent_v1__spawn_agent.multi_agent_v1__wait_agentwithtimeout_ms: 120000(or 180000 / 60000). Grok serializes the field as120000.0.This session also showed a second, separate observation: wrapping
wait_agentinside the code-modeexecisolate with a first-line// @exec: {"yield_time_ms": 180000}pragma still yielded the isolate at ~30s with empty output ("Script running with cell ID …") when the pragma was not the first line of the isolate source. That is a usage/host-tool issue, not this bug. The GitHub issue is only thetimeout_msfloat rejection.Version
2.27.0/deva228ed7410f148a9462b4db2eee2b0e31d004d05Operating system
macOS 27.0 (26A5378n)
Provider and model
xai / grok-4.6 (OpenCodex default provider; Codex App tool surface)
Logs or error output
Live wait that later succeeded with an integer timeout (agent was still running — not dead):
Screenshots and supporting files
N/A. Citations from this tree:
integer, notnumber:src/lib/tool-argument-integers.ts:49-53(declaresInteger),182-186(no schema → no-op).toolParameterSchemas.get(currentToolCall.name)/ wire name:src/bridge.ts:623-629,1654-1659.namespacedToolName(namespace, name)which for this tool ismulti_agent_v1__wait_agent:src/server/responses/collaboration.ts:121-126,src/types/tools.ts:30-32.yield_time_msis stilltype: "number"(src/adapters/cursor/tool-definitions.ts:49), so even a looked-up schema would skip integer repair for that sibling field.wait_agent.timeout_msis a Codex-nativeu64and needs the integer path.Likely remaining hole vs closed #1611: either the wait_agent schema is not in
toolParameterSchemasunder the name Grok emitted, or atype: "number"declaration prevents the integer rewrite. Both leave120000.0on the wire.Redacted configuration
{ "defaultProvider": "xai", "note": "local ocx on port 10100; no tokens included" }Checks