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

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

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

리뷰 · 우선순위 73 / 80

지금 dev HEAD 3a3f556e1. #2319 merge-train이 #2294 릴리스 SSH 자격증명 거부를 방금 넣었음. 이 이슈는 그 위. Codex App + 기본 xAI Grok(xai/grok-4.6). multi_agent_v1__wait_agent가 실행 전에 거절됨. 에러 문자열은 floating point 120000.0, expected u64. #1611 정수 수리가 src/lib/tool-argument-integers.ts에 있고 src/bridge.ts에 배선돼 있음. 그래도 .0이 남음. 라벨 bug/tools. 스플릿 이슈 아님.

현재 dev가 그 거절을 만듦. 수리는 스키마가 integer일 때만임. tool-argument-integers.ts:49-53 declaresInteger. type === "integer" 또는 배열에 integer. number는 아님. :126-144 coerceValue가 숫자면 integer 선언 + safelyIntegral일 때만 changed: true로 재직렬화. :182-186 스키마 없으면 원문 그대로. 테스트가 그걸 잠금. tests/tool-argument-integers.test.ts:59-62 never touches number-typed fields. temperature 1.0은 원문 1.0 유지. 브릿지 호출은 src/bridge.ts:623-629 스트림 closeCurrentToolCall, :1654-1659 비스트림 flushToolCall. 키는 toolParameterSchemas.get(currentToolCall.name). 맵은 src/server/responses/collaboration.ts:121-126 namespacedToolName. wait는 multi_agent_v1__wait_agent.

구멍 두 개. (1) Codex가 광고하는 JSON 스키마가 timeout_ms: number임. devlog/_plan/260816_codexrs_multiagent_v2_and_history_perf/001_upstream_multiagent_v2_evidence.md:134 V1 wait 선택 필드, :139 V2 wait도 number. 런타임 Rust는 u64. JSON number vs serde u64가 갈라짐. 스키마를 찾아도 declaresInteger가 false라 120000.0이 그대로 Codex로 감. #1611 EXEC_SCHEMA는 yield_time_ms: integer라 exec는 고쳐졌음. wait는 그 계약 밖. (2) Grok이 Bare 이름 wait_agent를 찍으면 맵 키가 안 맞음. 스키마 없음 → no-op. collaboration.ts:153-161 bare 키는 toolChoice가 그 이름을 줄 때만. auto면 안 들어감. 둘 다 살아 있으면 같은 증상.

#2320 본문이 Closes #2316을 달았음. 그 PR은 Cursor resource_exhausted 분류임. src/adapters/cursor/cursor-errors.ts. wait_agent랑 파일도 안 겹침. 머지하면 깃허브가 이 이슈를 닫음. 그거 금지. #2320에서 Closes를 지워라. 구현 PR 아직 없음. 이 이슈를 닫지 말 것. Cursor yield_time_ms는 src/adapters/cursor/tool-definitions.ts:49가 아직 type: "number"임. 본문이 말한 형제 필드. 이 티켓 범위 아님. 본문 두 번째 관찰(exec isolate pragma 첫 줄 아님)도 이 이슈 아님.

types.ts/config.ts 안 만짐. 스플릿 안 씹힘. 리베이스하지 말고 닫으라는 케이스 아님. #2188 L1–L9 사이드카 + routed vision(#2306) 이미 dev. x_search 넣지 말 것. Grok OAuth Chat 기본(#2255)/GUI 옵트인 Responses(#2266)/#2283이랑 다른 레인임. 프리뷰 배포 아님. #2292/#2293 윈도우 피커랑 안 겹침. 카탈로그는 Ox Alpha x-preview-f-free + deepseek-v4-flash-vision-exp. v2.29.0 태그됨. v2.30.0-preview.20260821 있음. 비전공자 유지. 기본 Grok에서 wait가 안 돌아서 73.

해결방안: 이 이슈는 열린 채 유지. #2320 Closes #2316 삭제. 수리 두 축. (a) coerceIntegerToolArguments가 timeout_ms처럼 Codex native u64 필드는 JSON number여도 적분 플로트를 고침. temperature 같은 일반 number는 지금 테스트대로 손대지 말 것. (b) 스키마 조회를 currentToolCall.name만이 아니라 namespacedToolName 별칭(wait_agent / multi_agent_v1__wait_agent / collaboration__wait_agent)으로도 함. 회귀는 timeout_ms 120000.0 + wait 스키마 type number → 120000, 스키마 키 mismatch도 동일, 1.5는 실패 유지, temperature 1.0은 원문 유지. 라벨 건드리지 말 것. 스플릿이 tool-argument-integers.ts/bridge.ts를 옮기면 리베이스하지 말고 닫고 다시 짜라. 지금은 그 정도 아님.

이 댓글은 grok-bot이 작성했습니다

devlog: backlog disposition program roadmap (work-phase 0, docs-only)

fix(tools): repair integral floats in native u64 tool fields

Merge from upstream (#8)

devlog: backlog disposition program roadmap (work-phase 0, docs-only)

fix(tools): repair integral floats in native u64 tool fields

Navigation Menu

Repository navigation

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

Client or integration

Area

Summary

Reproduction

Version

Operating system

Provider and model

Logs or error output

Screenshots and supporting files

Redacted configuration

Checks

리뷰 · 우선순위 73 / 80

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

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

Description

Client or integration

Area

Summary

Reproduction

Version

Operating system

Provider and model

Logs or error output

Screenshots and supporting files

Redacted configuration

Checks

Activity

lidge-jun commented on Aug 21, 2026

리뷰 · 우선순위 73 / 80

lidge-jun commented on Aug 22, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions