Skip to content

[Bug] Grok wait_agent timeout_ms still rejected as 120000.0 after #1611 integer repair #2316

Description

@lidge-jun

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

  1. Route Codex App / Codex Desktop through OpenCodex with default provider xAI Grok (xai/grok-4.6 in this session).
  2. Spawn a long-running subagent via multi_agent_v1__spawn_agent.
  3. Call multi_agent_v1__wait_agent with timeout_ms: 120000 (or 180000 / 60000). Grok serializes the field as 120000.0.
  4. 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

  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingtoolstool_calls, MCP, web-search / sidecar tools

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions