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

[goodwilliam0126]

Client or integration

Codex App

Provider or upstream service

xAI (xai/grok-4.6)

OpenCodex version

2.25.0

I also observed the same class of behavior on 2.22.0; upgrading to 2.25.0 did not resolve it.

Endpoint or capability

/v1/responses — Codex tool use / file editing (apply_patch / code-mode edit helpers)

Current behaviour

xai/grok-4.6 can understand that a code change is required and say that it is going to modify the project, but then fail to actually invoke an editing tool or change the file.

The notable part is that the same session often recovers immediately after a follow-up such as:

Check how to use the available tools and continue.

After that reminder, Grok starts calling the appropriate tool(s) and performs the edit normally.

This makes the failure look less like a missing tool or a provider error and more like a tool-affordance / tool-guidance problem: the model appears capable of using the edit path once reminded how to use the available tools.

The behavior is intermittent rather than a hard 400/500 failure. A turn can complete successfully from the proxy's perspective while the requested file modification never happens.

Expected behaviour

When Codex advertises an editing path to xai/grok-4.6, the model should receive sufficiently accurate tool semantics/guidance to use that path without requiring the user to restate how tool usage works.

For a request that clearly requires a file modification, Grok should either:

• invoke the advertised edit tool / code-mode helper and perform the edit; or
• return an explicit recoverable tool error explaining why it cannot.

It should not simply claim that it will modify the file and then finish without any edit/tool call.

Minimal redacted request or reproduction

1. Run OpenCodex 2.25.0 and use Codex App with model xai/grok-4.6.
2. Open a normal code repository.
3. Ask Grok to make a concrete source-code change that requires editing one or more files.
4. Observe a failing run where Grok explains/plans the modification but no edit tool is invoked and the file remains unchanged.
5. In the same thread, send a follow-up equivalent to:
   "Check how to use the available tools and continue."
6. Observe that Grok then invokes the editing path and successfully modifies the file.
7. Verify with git diff that the file changed only after the tool-use reminder.

A larger or multi-step edit may reproduce more reliably than a trivial one-line change.

Actual response or error

No provider HTTP error is required to reproduce this.

Failing turn:
- model says it will perform the requested modification
- no effective edit tool call is made
- target file remains unchanged
- turn may otherwise complete normally

Follow-up after reminding the model to inspect/use its tools:
- edit/tool calls begin immediately
- requested file modification succeeds
- git diff shows the change

Upstream documentation

xAI function calling documentation:
https://docs.x.ai/developers/tools/function-calling

OpenCodex already has an internal investigation specifically for xai/grok-4.6 edit-tool affordance:
https://github.com/lidge-jun/opencodex/blob/main/devlog/_plan/260817_cursor_toolcall_decode/030_phase3-xai-apply-patch-affordance.md

That investigation notes that the Codex freeform/custom apply_patch contract is translated through the xAI openai-chat path, and that some of the original freeform contract is lost. It also correctly notes that a simple live probe succeeded, so this report is intended to provide a real failing user case rather than claim that the existing hypothesis is already proven.

Suggested mapping or implementation notes

The existing Phase 3 investigation looks relevant, but this report does not assume its proposed root cause is definitive.

Useful next checks may be:

• capture the actual outgoing tool catalog/instructions on a failing xai/grok-4.6 turn;
• compare the failing turn with the immediately succeeding turn after the user says to inspect tool usage;
• distinguish top-level freeform apply_patch from code-mode tools.apply_patch / nested edit helpers;
• test a larger or multi-file edit rather than only a one-line probe;
• verify whether the model receives different tool guidance after continuation/history replay.

The most useful signal is that the model can perform the edit in the same conversation immediately after a tool-usage reminder.

Additional context and attachments

This is specifically the xai/grok-4.6 provider path in Codex App, not cursor/grok-4.6.

The issue remained reproducible after upgrading from OpenCodex 2.22.0 to 2.25.0, so Cursor-specific fixes such as #1673 / #1832 do not explain this case.

If needed, I can provide a redacted OpenCodex request/log capture from a failing run and the immediately succeeding run after the tool-usage reminder.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on a concrete Codex client requirement and xAI's documented function-calling interface.

[Ingwannu]

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.

[goodwilliam0126]

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.

[goodwilliam0126]

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.

[lidge-jun]

리뷰 · 우선순위 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이 작성했습니다

[goodwilliam0126]

예전에는 도구 사용법 확인해달라고 하면 해결이 됐는데 이제 그렇게 해도 해결이 안되요.

[lidge-jun]

리뷰 · 우선순위 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이 작성했습니다