Add diff/content field to FileUpdateChange in JSON output

Open 💬 6 comments Opened Apr 7, 2026 by gadgetman6
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Summary

In codex exec --json mode, file_change items only include {path, kind} per change — the actual diff/content is stripped during the mapping from the internal protocol to the exec JSON output.

The TUI mode renders full diffs because it receives the FileChange enum directly from the protocol layer (Add { content }, Delete { content }, Update { unified_diff }). But the exec JSON mapper at codex-rs/exec/src/event_processor_with_jsonl_output.rs:186-193 only copies path and kind, discarding the rest:

.map(|change| FileUpdateChange {
    path: change.path,
    kind: match change.kind {
        PatchChangeKind::Add => ExecPatchChangeKind::Add,
        PatchChangeKind::Delete => ExecPatchChangeKind::Delete,
        PatchChangeKind::Update { .. } => ExecPatchChangeKind::Update,
    },
})

Proposed change

Add a diff (or content) field to FileUpdateChange in codex-rs/exec/src/exec_events.rs:

pub struct FileUpdateChange {
    pub path: String,
    pub kind: PatchChangeKind,
    pub content: Option<String>,  // file content for Add/Delete, unified_diff for Update
}

And pass it through in the mapper.

Use case

We run codex exec --json programmatically and emit ATIF (Agent Trace Interchange Format) telemetry spans for each tool call. Without the diff/content, file_change spans only show which files were touched but not what changed — making them far less useful for debugging and session analysis.

View original on GitHub ↗

6 Comments

gadgetman6 · 4 months ago

PR with the fix: https://github.com/gadgetman6/codex/pull/1

Adds an optional content field to FileUpdateChange in exec events, passing through the diff field from ApiFileUpdateChange that was previously dropped during the mapping. Empty diffs are omitted via skip_serializing_if.

gadgetman6 · 4 months ago

The fix is tested and working in my fork.

etraut-openai contributor · 4 months ago

I don't think we'd consider this a bug. The code is working as designed. I'll change this to a feature request.

gadgetman6 · 4 months ago

Any update on when I can expect this to be prioritized?

etraut-openai contributor · 4 months ago

We generally prioritize feature requests based on community upvotes. This hasn't received any upvotes yet.

gadgetman6 · 1 month ago

@etraut-openai There seem to be some upvotes now, I've been maintaining my forked copy for ~3 months at this point, is there a way we could get this merged in?