Codex Desktop: full file content always fails to load in non-Git workspaces

Open 💬 0 comments Opened Jul 26, 2026 by Johnixr

What version of the Codex App are you using (From “About Codex” dialog)?

26.721.41059 (build 5848)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

In Review → Last turn, every modified file shows “Full file content failed to load” when the task workspace root is an ordinary directory rather than a Git repository. The partial hunk renders correctly, but clicking Retry always produces the same failure.

This is not related to file size or encoding in the observed case: it occurred for two readable UTF-8 text files of about 28 KB (Markdown) and 54 KB (JSONL). The underlying apply_patch operation succeeded and the files contain the expected changes.

I traced the failure to the full-file loading path:

  1. Codex core emits a partial Git-style unified diff and synthesizes blob OIDs from the in-memory old/new contents:
  1. When no Git root is found, the session uses the task cwd as the diff root:
  1. The turn-diff notification carries only the unified diff, not the full old/new contents or another content handle:
  1. In the installed desktop app, the full-file loader asks its Git worker to resolve the synthetic OIDs with cat-file. The worker first tries to obtain a worktree repository for the task cwd. If the cwd is not inside a Git repository, it returns an unknown error for every request, including the request that otherwise allows a disk fallback for the current file.
  2. The UI maps that unknown result to the retryable “Full file content failed to load” state, so Retry is deterministic and cannot recover.

What steps can reproduce the bug?

  1. Create a workspace that is not a Git repository:

``sh
mkdir -p /tmp/codex-non-git-workspace/project
printf 'line 1\nline 2\n' > /tmp/codex-non-git-workspace/project/example.md
``

  1. Start a local Codex App task with /tmp/codex-non-git-workspace as the workspace/cwd.
  2. Ask Codex to update project/example.md (the observed failure used apply_patch).
  3. Open Review → Last turn.
  4. Open the file diff and try to load the complete file context.
  5. Observe “Full file content failed to load”.
  6. Click Retry; the same error remains.

The equivalent Git lookup also fails as expected because the cwd is not a repository:

git -C /tmp/codex-non-git-workspace cat-file -e <synthetic-blob-oid>
# fatal: not a git repository

What is the expected behavior?

The full-file view should work for files in non-Git workspaces, or the UI should gracefully indicate that full context is unavailable without presenting a Retry action that cannot succeed.

For a last-turn diff, one possible non-Git fallback is:

  • read the current full file from disk;
  • reconstruct the previous side by reverse-applying and validating the recorded patch;
  • if the file changed after the turn or reconstruction fails, keep showing the partial diff and classify full context as unavailable rather than retryable.

Another option is for the backend/protocol to provide bounded old/new contents (or resolvable content handles) with the turn-diff event.

At minimum, “workspace is not a Git repository” should be represented as a non-retryable not-found/unavailable result rather than unknown.

Additional information

  • The issue is consistent across both modified files in the same turn.
  • The files remained readable throughout and the patch event contained the correct absolute paths.
  • Initial searches did not find an existing issue for this exact error and non-Git full-file loading path. Related reports about multi-repository detection or revert/undo failures have different symptoms.
  • Paths and file contents above are sanitized. I can provide a private trace if maintainers need it.

View original on GitHub ↗