Codex Desktop Environment: Commit/Push repeatedly fails at “Generate message”
Open 💬 1 comment Opened Jul 24, 2026 by zhuqunli
Codex app version
26.721.31836 (build 5828)
Platform
macOS 26.5.2 (25F84), Apple Silicon
What issue are you seeing?
In the Codex Desktop Environment/Git panel, clicking Commit or the Commit/Push flow repeatedly fails during Generate message. No commit message is produced and the UI only reports that the operation could not be completed.
The failure is consistent across retries, so the Environment Git UI cannot be used to commit or push the current workspace.
Steps to reproduce
- Open an existing local Git repository in Codex Desktop.
- Make changes in the workspace.
- Open the Environment/Git changes panel.
- Click Commit or use the Commit/Push flow.
- Wait for the automatic Generate message step.
- Observe that message generation fails with a generic “could not complete” error and no commit/push occurs.
Expected behavior
- Codex should generate a commit message and continue with the requested Git action.
- If Git permissions, staged state, diff size, remote type, or another prerequisite blocks the action, the UI should show the exact actionable error.
- The user should be able to enter a commit message manually when automatic generation fails.
Local verification and potentially relevant details
git status --short --branchsucceeds.- The current branch correctly tracks its remote branch.
git remote -vsucceeds and an SSH remote is configured.- Normal read-only Git inspection works in the Codex terminal environment.
- The current working tree is relatively large: more than 30 modified files plus multiple untracked files, with no files staged at the time of inspection.
- The current Codex permission profile exposes workspace source files as writable but
.gitmetadata as read-only. If the Environment Git action uses the same permission boundary, failure to write.git/indexor refs may be involved; this is an inference, not a confirmed root cause. - The current task has no attached App Terminal session, so the generic UI failure did not expose a lower-level error.
- No repository source code, repository name, or remote URL is included in this report.
Similar reports
- #16800 — Desktop “Stage all” fails while normal terminal Git works.
- #11327 — Desktop Git UI fails when sandboxing blocks writes to
.git/index.lockor other Git metadata.
Additional information
This report was submitted on behalf of a user who reproduces the failure every time they click the Environment Commit/Push control. The main usability issue is not only the failure itself, but that the UI reports no concrete reason and provides no manual-message fallback.
1 Comment
Additional reproducible evidence from a separate repository and a newer desktop build:
Uploaded diagnostics: Codex
/feedbackthread ID01a037e9-1c10-7bc2-9ee8-b6ae55931b42Environment
26.818.61809(build7019)26.6.2(25G83), arm640.149.0-alpha.4.3git 2.50.1 (Apple Git-155)Observed trigger
mainbranch is up to date with its remote.Redacted desktop-log evidence
The same exit-
129review-summary failure was recorded three times across desktop app restarts:06:17:13Zwith 2 untracked files, then07:07:37Zand07:14:33Zwith 4 untracked files.Git identity, remote connectivity, repository connectivity, and index state were healthy; there was no index lock. A temporary index staged all four files and
git diff --cached --checkpassed. Manually staging, committing, and pushing succeeded, and local/remote SHAs matched.No commit-message generation request appeared before the UI error. This points more narrowly to the untracked-file review-summary path constructing an invalid
--no-indexdiff by appending pathspecs after the two compared paths, rather than to Git authentication or permission failure.