File-change approval prompt is blank when reason is absent

Resolved 💬 5 comments Opened Aug 2, 2026 by sivatek Closed Aug 18, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

File-Change Approval Is Blank When Reason Is Absent

Summary

In Codex CLI 0.146.0, a file-change approval can show three blank
rows between its question and choices. The prompt then asks the user
to approve an action without identifying the action or its target.

This was reproduced through local and remote terminal clients on
macOS. Execution approvals are unaffected when their justification
is present.

Cause

ApplyPatchApprovalRequest supplies reason, cwd, and changes.
The TUI header renders only a nonempty reason; it does not use
cwd or the changed paths. With no reason, the header has no fields.

The existing snapshot also expects the filename and diff summary to
be absent.

Expected Result

Every file-change approval should identify the action and target:

Description: <reason or Apply proposed file edits>
Destination: <sorted absolute changed path>

The approval choices and omission of diff content should remain
unchanged.

Tested Fix

The proposed patch adds the two fields above. It uses the request
reason when available, supplies a fallback when it is absent, and
resolves each changed path against the request working directory.

Verified against official tag rust-v0.146.0:

cargo fmt --all -- --check passed;
the reason-present approval snapshot passed; and
a reason-absent regression test passed.

View original on GitHub ↗

5 Comments

chanse-syres · 25 days ago

I reproduced this on the current main branch and then traced it to the TUI approval header. The approval request contains the working directory and the changed paths, but when no reason is supplied, the modal renders the question and choices without any description or target files.

I have a minimal local fix that:

-> Gives a clear fallback explanation when the reason is not present;
-> Shows the impacted destination paths, fixed against the request working directory;
-> Keeps the existing approval choices and behaviors unchanged;
-> Adds regression coverage for both reason present and reason absent prompts.
-> I was able to reproduce the blank prompt before the change, which confirmed the focused tests now pass afterward, and then ran the necessary formatting, linting, and test checks.

If this approach matches the UX, I’d be happy to open a focused PR for it. Please let me know if you’d like me to continue.

sivatek · 25 days ago

A tested implementation is available for maintainer reference:

https://github.com/sivatek/codex-upstream-patches/commit/30f8859

It is based on current openai/codex main and changes only the TUI
renderer, its file-change approval snapshot, and test setup.

Direct current-main evidence:

the reason-present approval snapshot passes;
the reason-absent fallback and destination assertions pass;
no snapshots are pending; and
cargo fmt --all -- --check passes.

The full TUI run completed 3,350 of 3,351 tests successfully. The
unrelated focus/palette timing test failed at its 500 ms deadline and
also failed when rerun alone.

I understand external PRs are invitation-only. The branch is ready if
a maintainer decides that a pull request would be useful.

sivatek · 25 days ago

Correction to my earlier implementation note: a live test exposed that
commit 30f8859 rendered Description: but not Destination: on the
embedded app-server path. That commit was incomplete.

The corrected current-main implementation is:

https://github.com/sivatek/codex-upstream-patches/commit/405f226

The root cause was loss of file changes between the buffered
ItemStarted notification and the active approval request. The new
commit recovers those changes for the active request, renders each
exact destination, and renders Destination: unavailable for an
incomplete legacy request so the prompt does not imply informed
approval.

Direct evidence:

the active-route destination recovery test passes;
the incomplete-request destination snapshot passes;
the existing inactive-route recovery test passes; and
just fix -p codex-tui passes with no warnings.

A rebuilt 0.146.0 binary is still undergoing a real-prompt acceptance
test. I will add that result separately rather than overstate it here.

I understand external PRs are invitation-only. The branch is ready if
a maintainer decides that a pull request would be useful.

sivatek · 25 days ago

Live acceptance is now complete for the corrected implementation:

https://github.com/sivatek/codex-upstream-patches/commit/405f226

I rebuilt Codex 0.146.0 for arm64, launched the installed binary in a
fresh tmux session, and requested one file edit under read-only
sandbox policy. The native prompt displayed
Description: Apply proposed file edits and a Destination: row
containing the full requested path.

I denied the request with Escape and verified that the target file was
absent. This confirms the embedded active-request route, not only a
renderer unit test.

etraut-openai contributor · 9 days ago

This will be fixed in 0.149.0.