VS Code Codex diff fails to load full file content

[Redbird10]

What version of the IDE extension are you using?

26.513.21555

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Darwin 25.4.0 arm64 arm (Mac OS)

What issue are you seeing?

In the VS Code Codex diff view, a simple change to a tracked file fails to load the full file content.

The UI shows:

Full file content failed to load

with a Retry button. Clicking Retry does not resolve the issue.

What steps can reproduce the bug?

Feedback ID: 019e45e7-3599-7a50-b966-f908ecaebd35

1. Open a git repository in VS Code with the Codex extension enabled.

2. Ask the Codex extension to modify a tracked file. In my repro, the file was robots.txt.

3. Codex made a simple one-line insertion:

   # https://www.robotstxt.org/robotstxt.html
   +# Site crawler access rules
   User-agent: *
   Disallow:

4. Open the Codex diff view for that change by clicking the review button in the chat.

5. Observe that the diff view shows the file header, the full-content load failure, and only a few diff lines:

   robots.txt
   Full file content failed to load
   <a few diff lines>
   

6. Click the Retry button.

7. The same failure remains.

What is the expected behavior?

No response

Additional information

Diagnostic Notes From Local Instrumentation

The following section is based on local instrumentation added by Codex itself while debugging. Please treat it as reference material, not as a definitive fix proposal.

After adding temporary logging to the local installed extension bundle, the failing full-content load appeared to come from the diff webview calling:

git.request({
  method: "cat-file",
  params: {
    cwd,
    path,
    oid,
    fallbackToDisk,
    operationSource: "thread_diff"
  }
})

The debug output showed that the diff metadata used an absolute path:

diff.name: /private/tmp/codex-review-repro/robots.txt
workspaceRoot: /private/tmp/codex-review-repro

But the cat-file request appeared to expect a repository-relative path:

robots.txt

With the absolute path, both sides initially failed:

{
  oldResult: {
    type: "error",
    error: { type: "not-found" }
  },
  newResult: {
    type: "error",
    error: { type: "not-found" }
  }
}

After locally normalizing the path from:

/private/tmp/codex-review-repro/robots.txt

to:

robots.txt

the new side loaded successfully from disk, but the old side still failed:

{
  oldResult: {
    type: "error",
    error: { type: "not-found" }
  },
  newResult: {
    type: "success",
    lines: [
      "# https://www.robotstxt.org/robotstxt.html\n",
      "# Site crawler access rules\n",
      "User-agent: *\n",
      "Disallow:\n"
    ]
  },
  nextFallbackToDisk: false
}

The old side appeared to fail because the diff metadata did not include prevObjectId, and the request effectively had:

oid: null
fallbackToDisk: false

The extension-side cat-file handler appears to return not-found for that combination.

As a local experiment only, I patched the installed extension to resolve the old side with:

git rev-parse HEAD:<path>

and then read that blob with git cat-file. With that local experiment, the full-content load succeeded and the Retry button disappeared.

Possible Cause

Based on the above local investigation, the failure may involve two related issues:

1. The partial diff metadata may provide an absolute file path where the full-content loader expects a repo-relative path.
2. The old-side full-content loader may not have a fallback when prevObjectId is missing and fallbackToDisk is false.

Again, this diagnosis was produced from local instrumentation and should be treated as a debugging lead rather than a confirmed root cause.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Undo failed in latest extension (26.513) #23326

Powered by Codex Action

[Redbird10]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Undo failed in latest extension (26.513) #23326

Powered by Codex Action

Undo and reapply seems to be working on my side.
And this issue only happens in the VS Code extension. The same conversation, when opened in the Mac OS Codex app, is working correctly without that issue.

[RainbowPopsicle]

I encountered the same problem on win11.

[YuHan-233]

I also encountered the same problem in the Codex application of Windows 11. The issue doesn't occur when I disable the "Load Complete File" option. Could it be because the context of the complete file is too lengthy?

[guojinjim]

I hit what looks like the same underlying bug in Codex Desktop, with a worktree/cwd mismatch variant.

Environment:

• Codex Desktop / app-server thread from cli_version: 0.133.0
• macOS Darwin arm64
• The UI was localized, but the visible error was the equivalent of Full file content failed to load, with a retry button.

Anonymized repro shape:

Thread cwd:
  /Users/example/src/project/service

Actual file modified by the agent:
  /Users/example/src/project/.worktree/feature-branch/service/path/to/file_test.go

The patch/diff itself rendered correctly because the patch_apply_end event had the absolute changed-file path and unified diff. However, when the diff viewer tried to expand/load the full file content for the changed file, it showed the full-content load failure.

In this case the target file still existed on disk and was readable after the failure:

/Users/example/src/project/.worktree/feature-branch/service/path/to/file_test.go

So this does not look like a missing-file or permission issue. It looks consistent with the diagnosis above: the diff metadata/full-content loader does not consistently handle absolute paths, or it resolves/validates the file against the thread cwd/workspace root instead of the actual worktree path recorded in the patch event.

Expected behavior:

• If a patch event records an absolute path in a different git worktree than the thread's original cwd, the diff viewer should still load the full file content from that recorded path, or from the correct worktree/repo-relative path.
• If loading fails, the UI should expose the underlying reason/path used for fs/readFile/cat-file instead of only showing the generic full-content failure message.

This seems related to #23709 rather than a separate issue, so adding it here as another data point.