Regression: Codex cannot publish a committed branch to an already connected GitHub repository

Regression: Codex cannot publish a committed branch to an already connected GitHub repository

Severity

High — completed work is left inside a Codex-managed local checkout that the user cannot access or publish.

Environment

• Codex Desktop on Windows
• GitHub application shown as connected
• GitHub, Review Follow-up, CI Debug, and Publish Changes skills enabled
• GitHub plugin version shown in the UI: 0.1.8-2841cf9749ae
• Repository: Faerdraug/darkover-nexus
• Branch: sprint-075i-genealogy-union-view-model
• Commit ready to publish: 91457043e62c2f74b9ab98ef527237de79891e19
• Worktree clean; branch is one commit ahead of the remote branch

Expected behavior

As in previous Codex tasks for the same repository, after the user explicitly asks to push and approves the action,
Codex should publish the committed branch using either Git or the connected GitHub Publish Changes workflow.

Actual behavior

1. A direct sandboxed git push -u origin sprint-075i-genealogy-union-view-model cannot reach GitHub on port 443.
2. The required escalated execution is rejected by Codex's approval reviewer with:

This push would send private workspace code to GitHub, which is not established here as a trusted internal or explicitly approved third-party destination.

1. The user explicitly confirms the exact commit, repository, and destination branch.
2. The approval reviewer rejects the push again, even after that explicit confirmation.
3. The GitHub application is connected and Publish Changes is enabled in Codex.
4. A new Publish Changes attempt then fails with:

Publication bloquée : GitHub CLI (gh) n’est pas installé ou accessible dans le PATH.

1. gh was never required for earlier pushes from Codex to the same repository.
2. The repository checkout containing the commit is Codex-managed and is not directly accessible to the user, so

asking the user to run git push from that checkout is not a workable fallback.

Steps to reproduce

1. Open a Codex Desktop task backed by a Codex-managed checkout on Windows.
2. Connect the GitHub application and enable Publish Changes.
3. Commit a change on a local branch tracking an existing branch in a private GitHub repository.
4. Ask Codex to push the branch.
5. Explicitly approve the exact repository, branch, and commit when prompted.
6. Observe that the approval reviewer still rejects direct git push as external disclosure.
7. Try Publish Changes.
8. Observe that Publish Changes requires a separately installed and authenticated gh executable despite the

GitHub connector being connected.

Regression and impact

• Previous Codex tasks could push branches to this repository without GitHub CLI.
• The current combination of managed checkout, approval policy, and Publish Changes creates a dead end:

direct Git push is forbidden, while the approved connector workflow unexpectedly depends on an unavailable CLI.

• Explicit user consent does not unblock the operation.
• The user cannot directly access the checkout that contains the unpublished commit.
• This makes completed work appear lost or forces manual bundle/patch recovery.

Requested fix

Any one of the following would resolve the regression:

1. Treat a repository authorized through the connected GitHub application as an approved publication destination.
2. Allow a scoped git push after explicit user approval of repository, branch, and commit.
3. Make Publish Changes use the connected GitHub application without requiring a separately installed gh CLI.
4. Bundle GitHub CLI with Codex when Publish Changes requires it.
5. Ensure Codex-managed checkouts are accessible to the user or provide a first-class export/publish fallback.

Available attachments

• Screenshot showing the GitHub application connected and Publish Changes enabled.
• Git patch and verified bundle containing the unpublished commit.