[Compatibility] xai/grok-4.6 can skip Codex edit tools until explicitly reminded how to use tools #2048

Activity

1. github-actions

   added

   provider-compatibilityProvider compatibility reportsProvider compatibility reports

   providerProvider adapters, OpenAI-compat presets, upstream API quirksProvider adapters, OpenAI-compat presets, upstream API quirks

   toolstool_calls, MCP, web-search / sidecar toolstool_calls, MCP, web-search / sidecar tools

   on Aug 18, 2026
2. Ingwannu commented on Aug 18, 2026

   

   Ingwannu

   on Aug 18, 2026

   Owner

   More actions

   Thanks — the same-thread recovery after a tool-usage reminder is useful evidence, but it is not yet enough to distinguish an OpenCodex tool-catalog/continuation defect from an intermittent model decision not to call a correctly advertised tool.

   Please attach one redacted failing request and the immediately succeeding request from the same conversation, including:

   • the outbound tools entries for apply_patch / code-mode exec
   • tool_choice and any tool-related system/developer guidance
   • the assistant response events for both turns
   • whether the failing path advertised top-level apply_patch, nested tools.apply_patch through exec, or both

   Please remove authorization headers, account IDs, prompt/file contents, and tool arguments. With that pair we can compare the actual wire contract and continuation history. I am marking this needs-info rather than changing global xAI prompts based on a model-behavior hypothesis.
3. Ingwannu

   added

   needs-infoWaiting on reporter for a concrete spec or reproductionWaiting on reporter for a concrete spec or reproduction

   on Aug 18, 2026
4. goodwilliam0126 commented on Aug 18, 2026

   

   goodwilliam0126

   on Aug 18, 2026

   ContributorAuthor

   More actions

   Thanks — I captured a Codex Desktop rollout from the same xai/grok-4.6 session that provides some additional client-side evidence.

   This does not yet include the final OpenCodex → xAI outbound tools / tool_choice body you requested, so I am not presenting it as a complete answer to the needs-info request. However, it clarifies what happened on the Codex side after an explicit tool-usage reminder.

   Environment:

   model: xai/grok-4.6
   Codex Desktop CLI/runtime: 0.148.0-alpha.9
   reasoning effort: xhigh
   

   The session instructions explicitly included:

   Use `apply_patch` for local file edits.
   Do not create or edit files with `cat` or other shell write tricks.
   Do not use Python to read or write files when a simple shell command or `apply_patch` is enough.
   

   Exact user reminder

   Original user message, verbatim:

   도구 사용법 다시 확인하고 수정 시도해봐
   

   Translation:

   Check how to use the tools again and try the modification.

   The assistant then visibly responded:

   도구 호출부터 다시 점검하고, 작업 트리 상태를 확인한 뒤 리팩터링을 이어서 적용하겠습니다.
   

   and shortly after:

   `apply_patch`부터 다시 확인하고, 이어서 리팩터링을 적용하겠습니다.
   

   Actual retry path

   The rollout records the outer Codex call as:

   name: exec
   

   with a nested call equivalent to:

   const result = await tools.apply_patch(
     "*** Begin Patch ***\n" +
     "*** Update File: [REDACTED_WORKSPACE]/utils/interactions.py\n" +
     "[REDACTED_PATCH_BODY]\n" +
     "*** End Patch ***"
   );

   So the observed failing edit path was:

   exec
     -> tools.apply_patch(input: string)
   

   The string recorded in the rollout visibly begins with:

   *** Begin Patch ***
   

   The immediately returned error was:

   Script failed
   Wall time 0.0 seconds
   Output:
   
   Script error:
   apply_patch verification failed: invalid patch: The first line of the patch must be '*** Begin Patch'
   

   What the model did after the retry failed

   After that failure, the assistant visibly said:

   `apply_patch`는 이 환경에서 패치 헤더를 못 읽고 있습니다. 파일 쓰기로 리팩터링을 이어서 적용하겠습니다.
   

   Translation:

   apply_patch cannot read the patch header in this environment. I will continue the refactoring using file writes.

   The subsequent reasoning record indicates that the model attributed the failure to the nested exec / apply_patch path and decided to abandon apply_patch in favor of exec_command plus Python/pathlib file writes.

   I am summarizing the reasoning record here rather than reproducing hidden reasoning verbatim.

   The rollout then records an actual fallback call of the form:

   const result = await tools.exec_command({
     cmd: "python3 -c 'from pathlib import Path; Path(\"/tmp/[REDACTED]\").write_text(\"ok\\n\", encoding=\"utf-8\"); ...'",
     workdir: "[REDACTED_WORKSPACE]",
   });

   which succeeded:

   Script completed
   Wall time 0.3 seconds
   Output:
   ok
   

   Relevant earlier evidence from the same session

   Before the explicit reminder, the model had already inspected its model-visible tool catalog. The apply_patch entry exposed to it was:

   The `apply_patch` tool can be used to edit files. This is a FREEFORM tool, so do not wrap the patch in JSON.
   
   exec tool declaration:
   
   declare const tools: {
     apply_patch(input: string): Promise<unknown>;
   };
   

   So, on the client side, the model had evidence that:

   - apply_patch existed
   - it was FREEFORM
   - it accepted a string
   - it was callable as tools.apply_patch(input: string)
   

   Despite the explicit user reminder and a retry using that advertised nested call shape, the session still failed to recover to a successful apply_patch edit and instead switched to executable file-writing code.

   What this establishes

   This reproduction is different from a simple case where the model merely decides not to call a tool:

   1. The user explicitly asked it to re-check tool usage.
   2. The model acknowledged that request.
   3. It retried the advertised nested tools.apply_patch(input: string) path.
   4. The recorded string visibly began with *** Begin Patch ***.
   5. The local verifier rejected it with a first-line error.
   6. The model then abandoned apply_patch and used Python/file writes through exec_command.

   I do not think this rollout alone proves whether the root cause is in OpenCodex translation, Codex nested-tool handling, or Grok's tool behavior.

   It also does not contain the final OpenCodex → xAI serialized request, so the following items from your needs-info request are still missing:

   - outbound tools entries as sent to xAI
   - tool_choice
   - final tool-related system/developer guidance after OpenCodex translation
   

   I can provide a narrowly redacted rollout excerpt containing the user message, assistant events, nested apply_patch call, verifier error, and fallback call if useful. The full rollout contains local project contents and paths, so I would prefer not to attach it unredacted.
5. goodwilliam0126 commented on Aug 18, 2026

   

   goodwilliam0126

   on Aug 18, 2026

   ContributorAuthor

   More actions

   If there’s a recommended way to capture the full outbound request, including tools, tool_choice, and the final tool-related system/developer guidance sent to xAI, I’d really appreciate instructions on how to collect those detailed logs.
6. lidge-jun commented on Aug 19, 2026

   

   lidge-jun

   on Aug 19, 2026

   Owner

   More actions

   리뷰 · 우선순위 28 / 80

   xai/grok-4.6이 파일을 고치겠다고 말하고도 apply_patch/code-mode 헬퍼를 안 부른다. 같은 스레드에서 “도구 쓰는 법을 확인하고 계속해”라고 하면 그때야 편집이 된다. HTTP 에러는 없고, 프록시 턴은 성공으로 끝난다. 기본 native 경로가 아니라 라우티드 xAI 도구 안내 문제라 28이다. 라벨이 needs-info인 이유가 있다. 간헐적이고 리마인드로 풀린다.

   라우티드 모델은 applyRoutedCodexToolMode()가 code_mode_only를 찍는다. 편집은 최상위 와이어 도구가 아니라 exec 안의 tools.apply_patch(...)일 수 있다. src/adapters/tool-catalog-nudge.ts 주석이 그걸 말한다. apply_patch를 이웃 도구 금지 목록에 넣으면 모델이 python3 heredoc으로 도망가서 일부러 빼 두었다.

   xAI는 src/adapters/openai-chat.ts를 탄다. shouldInjectNonOpenAIToolCatalogNudge()는 ChatGPT 호스트가 아니면 넛지를 넣는다. xAI baseUrl이면 넛지는 들어간다. 같은 파일의 isXaiSchemaTarget()은 스키마를 xAI가 받는 형태로 접는 쪽이지, 편집 도구를 숨기거나 강제하지 않는다. 스키마 정규화가 도구를 “없음”으로 보이게 했는지는 실패 턴의 아웃바운드 tools 목록이 있어야 안다.

   실패가 프록시 가드가 아니라 모델이 도구를 생략한 것이면, 강제 tool_choice나 가짜 apply_patch 성공을 심는 패치는 위험하다. 리마인드 한 줄이 고친다는 건 안내 텍스트/중첩 헬퍼 설명이 약하다는 쪽에 가깝다. 요청 바디·파일 경로·토큰은 이 이슈에 넣지 말고, 광고된 도구 이름과 code-mode 여부만 있으면 된다.

   해결방안

   먼저 실패 턴과 리마인드 성공 턴의 아웃바운드 도구 목록(이름만)과 tool_mode를 비교한다. exec만 있고 apply_patch가 중첩이면, buildNonOpenAIToolCatalogNudgeForTools()에 tools.apply_patch(...) 문장을 더 분명히 넣는 쪽이 코드로 손댈 후보다. 최상위 apply_patch가 이미 있는데도 안 부르면 모델 쪽이고, OpenCodex가 호출을 강제하지는 않는다. 그 증거 없이는 패치는 추측하지 않음. 가드나 400 경로를 느슨히 풀어 편집을 성공으로 위장하지 않는다.

   이 댓글은 grok-bot이 작성했습니다
7. goodwilliam0126 commented on Aug 19, 2026

   

   goodwilliam0126

   on Aug 19, 2026

   ContributorAuthor

   More actions

   예전에는 도구 사용법 확인해달라고 하면 해결이 됐는데 이제 그렇게 해도 해결이 안되요.
8. lidge-jun commented on Aug 19, 2026

   

   lidge-jun

   on Aug 19, 2026

   Owner

   More actions

   리뷰 · 우선순위 28 / 80 · 종결

   이거 커서 툴 쪽 작업 때 이미 들어갔음. xai/grok-4.6이 고치겠다고만 하고 apply_patch를 안 부르던 건, 카탈로그/안내가 프리폼 계약을 흘려서 생긴 거였음. “도구 쓰는 법 확인하고 계속해”라고 하면 살아나던 게 그 신호임.

   지금 dev에선 그 안내가 공용 src/adapters/tool-catalog-nudge.ts로 빠졌고, xAI가 타는 openai-chat 경로에도 그대로 주입됨. 커서 전용 #1673 / #1832만의 이야기가 아니라, 같은 캠페인에서 라우티드 쪽까지 같이 고친 거임. apply_patch는 이웃 도구 금지 목록에 안 넣음 (코드모드에선 exec 안 tools.apply_patch로 살아 있어서, 막으면 파이썬 히어독으로 도망감).

   남은 잔여가 있으면 #2115(라우티드 코드모드 편집 안내)가 그 후속임. 이 이슈 자체는 재현 케이스 + 리포트로 역할 끝났으니 닫음. 또 스킵되면 버전/모델 찍고 다시 열어주면 됨.

   해결방안: 추가 패치 없음. 재발 시 tool-catalog-nudge 주입 여부랑 outbound 카탈로그부터 보면 됨.

   이 댓글은 grok-bot이 작성했습니다
9. lidge-jun

   closed this as completedon Aug 19, 2026