Skip to content

[Bug]: Diff view captures only the first few edits from a turn and shifts the rest to the next turn #1434

Closed
#9841
Closed
[Bug]: Diff view captures only the first few edits from a turn and shifts the rest to the next turn#1434
#9841
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@a-chugunov
a-chugunov
opened on Mar 26, 2026

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web, likely others as well

Summary:

When Codex performs a long series of file edits in a single turn, the diff panel often captures only the first few files for turn 1. The remaining files are still modified on disk, but they do not show up in the turn 1 diff. If a second prompt is sent afterward, even something trivial like thank you, the missing files usually appear in the next turn's diff instead.

This makes the first turn look incomplete and shifts part of its filesystem changes into a later turn, which breaks turn-level diff accuracy.

Steps to reproduce

  1. Start from a clean git worktree.
  2. Open a new Codex thread in T3 Code.
  3. Send the prompt from PROMPT.md (below).
  4. Wait for the first turn to finish.
  5. Open the diff panel for turn 1.
  6. Observe that only the first few generated files are shown.
  7. Send a second prompt such as thank you.
  8. Open the diff panel again.
  9. Observe that the remaining generated files now appear in the later diff, even though they were created during turn 1.

PROMPT.md:

Create exactly 18 new TypeScript files in src/generated named file01.ts through file18.ts.

Each file must be exactly 40 lines long and must contain valid TypeScript.

Use this exact structure in every file:

  • line 1: export const file01 = [ for file01.ts, export const file02 = [ for file02.ts, and so on
  • lines 2 through 39: one string entry per line
  • each string entry must say both the file name and the actual file line number for that line
  • line 40: ] as const;

Example for src/generated/file01.ts:

  • line 2 should be "file01.ts line 02",
  • line 3 should be "file01.ts line 03",
  • line 39 should be "file01.ts line 39",

Important constraints:

  1. Use exactly one tool call per file edit.
  2. Do not batch multiple file edits into one tool call.
  3. If you use apply_patch, each apply_patch call must touch only one file.
  4. Do not generate the files with a loop, script, heredoc, or codegen command.
  5. Create the files one at a time.
  6. Do not make any extra file edits after the 18 files are created.
  7. Stop immediately after all 18 files have been created.

If src/generated does not exist yet, create it as needed, but still keep every file edit to one tool call per file.

Expected behavior

Turn 1 should contain all files created during the first turn.

If the second prompt does not edit anything, the next turn should have an empty diff.

Actual behavior

Turn 1 frequently contains only the earliest file edits.

The remaining file edits from turn 1 often show up only after a second prompt creates another checkpoint boundary.

Impact

Major degradation or frequent failure

Version or commit

t3@0.014

Environment

MacOs 26.2
node v24.14.1
codex-cli 0.116.0

Screenshots, recordings, or supporting files

Screenshot 2026-03-26 at 10.18.20.png

Image

Workaround

Always have a follow-up small prompt, ie 'thank you', to force git diff to pick up remaining diffs.
This will not fix the issue, but at least keep the follow-up git diffs cleaner.

Activity

  1. a-chugunov
    added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Mar 26, 2026

  2. a-chugunov commented on Apr 14, 2026

    @a-chugunov
    a-chugunov
    on Apr 14, 2026
    Author

    Still an issue in 0.0.17.

    Possibly only codex suffers from this though, Claude code seems fine.

    Likely cause - too early do a turn snapshot of the diff.

  3. juliusmarminge
    marked [Feature]: Add close button to toasts for accessibility and easier dismissal #1832 as a duplicate of this issue on Apr 17, 2026
  4. juliusmarminge
    marked [Bug]: Changed file list is not correct #1875 as a duplicate of this issue on Apr 17, 2026

  5. a-chugunov commented on Apr 22, 2026

    @a-chugunov
    a-chugunov
    on Apr 22, 2026
    Author

    Likely cause and potential fix:

    we’re creating a placeholder checkpoint on the first turn.diff.updated, then immediately replacing it with a real git snapshot at that moment. If more edits happen later in the same turn, that early snapshot becomes the “final” diff and the remaining changes spill into the next checkpoint boundary.

    The smallest safe fix looks like: keep the placeholder from turn.diff.updated, but stop treating it as a signal to take the real git snapshot; let turn.completed own the final capture.

  6. GTechMicah commented on Aug 28, 2026

    @GTechMicah
    GTechMicah
    on Aug 28, 2026

    Yeah I've seen this happen basically all the time myself (running windows 11 with codex, working on VB.Net and flutter projects).
    Basically whenever T3Code show a list of changed files but it isn't finished making the changes then when it finishes the final list of file changes will just be the initial changes which will not include all the changes the AI made. You can pull in the list of changes between what it showed and what it finished with by sending something like 'thank you" into the chat, but you'd have to remember to do that, and an issue like this makes you not trust the program as much as you would like (because you don't see at a glance everthing it changed [including whole files it's not showing and other parts of files it isn't showing]).

    This happens quite regularly. The ChatGpt app itself doesn't have this problem, but this (to me at least) is one of the most annoying bugs with the particular development tool. It's a great tool all in all, but i would love to see this issue fixed sooner rather than later please.

    This is still happening in the latest release of T3.

  7. GTechMicah commented on Aug 28, 2026

    @GTechMicah
    GTechMicah
    on Aug 28, 2026

    Is this a duplicate: #932

  8. juliusmarminge
    marked BUG: Missing edited files in the turns panel #932 as a duplicate of this issue on Sep 1, 2026
  9. juliusmarminge
    marked [Bug]: Codex edited files, but missing in the diff #5191 as a duplicate of this issue on Sep 1, 2026

  10. juliusmarminge commented on Sep 5, 2026

    @juliusmarminge
    juliusmarminge
    on Sep 5, 2026
    Member

    Triage

    Report: When Codex edits many files one-at-a-time in a single turn, the turn-1 diff often includes only the first few files. Remaining on-disk edits show up on the next turn after a trivial follow-up (e.g. thank you) creates another checkpoint. Reproduced on macOS and Windows; reporter notes Claude Code does not show the same split. Impact is frequent incomplete/shifted diffs.

    Likely area: Checkpoint timing, not the diff UI.

    • apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts — first Codex turn.diff.updated creates a status: "missing" placeholder via thread.turn.diff.complete
    • apps/server/src/orchestration/Layers/CheckpointReactor.ts — captureCheckpointFromPlaceholder immediately replaces that placeholder with a real git snapshot; later captureCheckpointFromTurnCompletion then skips because a non-missing checkpoint already exists
    • Related projection/client handling: apps/server/src/orchestration/projector.ts, apps/server/src/orchestration/Layers/ProjectionPipeline.ts, packages/client-runtime/src/state/threadReducer.ts
    • Codex-specific trigger: apps/server/src/provider/Layers/CodexAdapter.ts (turn.diff.updated)

    That matches the reporter’s diagnosis: the first mid-turn diff update is treated as the final snapshot, so later edits in the same turn land on the next checkpoint boundary.

    Related:

    Type / severity: Confirmed bug (not enhancement). Frequent, user-visible, breaks turn-level diff accuracy. Enough repro + code evidence; not Codex-upstream — T3 is snapshotting too early.

    Next step: Ready for fix. No more repro needed. Review/land #9841 rather than opening another PR. Keep this issue open until that lands.

  11. juliusmarminge
    added
    via-triageFiled through npx t3 triage
    and removed
    needs-triageIssue needs maintainer review and initial categorization.
    on Sep 5, 2026
  12. juliusmarminge
    closed this as completedin #9841on Sep 5, 2026

  13. GTechMicah commented on Sep 8, 2026

    @GTechMicah
    GTechMicah
    on Sep 8, 2026

    @juliusmarminge thank you for fixing this, much appreciated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions