IntelliJ integration rejects valid apply_patch move hunks with ACP parse error

Summary

The IntelliJ Codex integration appears to reject valid apply_patch move hunks before the tool call completes.

Standalone Codex does not show this behavior in the same workflow, so this looks specific to the IntelliJ integration path rather than the core patch format itself.

Reviewed date: 2026-04-13.

Problem

When Codex in IntelliJ tries to move a file using apply_patch with the documented move header:

*** Begin Patch
*** Update File: <old path>
*** Move to: <new path>
@@
...
*** End Patch

the integration fails before the move is applied and surfaces an ACP initialization / patch parse error.

Observed error:

Failed to initialize ACP process. Process terminated with exit code: 1. Process output:
53 |             }
54 |             else if ((/^@@/).test(line)) {
55 |                 index.hunks.push(parseHunk());
56 |             }
57 |             else if (line) {
58 |                 throw new Error('Unknown line ' + (i + 1) + ' ' + JSON.stringify(line));
                               ^
error: Unknown line 12 "Moved to: /Users/.../LogFileQueryServiceImpl.kt"
      at U (node_modules/diff/libesm/patch/parse.js:58:27)
      at S6 (node_modules/diff/libesm/patch/parse.js:144:9)
      at dN (node_modules/diff/libesm/patch/apply.js:30:19)
      at r3 (src/CodexToolCallMapper.ts:261:24)
      at async sU (src/CodexToolCallMapper.ts:42:31)
      at async createItemEvent (src/CodexEventHandler.ts:183:30)
      at async createUpdateEvent (src/CodexEventHandler.ts:73:35)
      at async handleNotification (src/CodexEventHandler.ts:55:40)

Bun v1.3.11 (macOS arm64)

Important detail: this occurred in the IntelliJ integration flow while moving implementation files into a dedicated package/directory. A standalone Codex instance did not exhibit the same issue.

Why It Matters

This blocks a normal refactoring operation that should be representable as a move hunk rather than a delete-and-recreate.

Practical impact:

• file moves fail in the IDE integration,
• the agent has to fall back to shell moves or rewrite files manually,
• the integration behaves differently from standalone Codex,
• users lose confidence in whether apply_patch grammar is actually supported consistently across surfaces.

Code References

Relevant stack frames from the failing integration output:

• node_modules/diff/libesm/patch/parse.js:58
• node_modules/diff/libesm/patch/parse.js:144
• node_modules/diff/libesm/patch/apply.js:30
• src/CodexToolCallMapper.ts:261
• src/CodexToolCallMapper.ts:42
• src/CodexEventHandler.ts:183
• src/CodexEventHandler.ts:73
• src/CodexEventHandler.ts:55

Proposed Fix Envelope

• Verify that the IntelliJ integration accepts the same apply_patch move grammar as standalone Codex.
• If the integration rewrites patch headers internally, ensure *** Move to: is preserved exactly.
• If the ACP bridge is translating the patch into a different parser format, normalize move hunks before handing them to the parser.
• Add an integration-level regression test specifically for a valid file move patch.

Introduction History

Not investigated beyond the current failing integration behavior. The main observed fact is that the bug reproduces in IntelliJ integration but not in standalone Codex.

Suggested Test Scenarios

• Regression scenario: submit an apply_patch payload containing *** Update File: plus *** Move to: and confirm the move succeeds in the IntelliJ integration.
• Control scenario: submit a normal non-move update hunk and confirm patch application still succeeds.
• Cross-surface scenario: run the same move patch through standalone Codex and IntelliJ integration and assert consistent behavior.
• Error-shape scenario: if the patch is actually malformed, surface a grammar-specific validation error rather than an ACP initialization failure.