I recently set up a GPT-5 agent (Plus account level) connection to a private GitHub repo (personal account, not enterprise) and have the agent successfully reading from the repo. However, the agent states that it can’t create a PR because it doesn’t have write access. When I look at the ChatGPT Codex Connector configuration in GitHub I see that it has, under Permissions, “Read and write access to actions, code, issues, pull requests, and workflows” and I see that the repo in question is in the list of selected repos. I’ve tried removing the connector and starting from scratch but keep running into this same issue.
The same is happening to me, codex was sending push releases to Github but now it wont due to permissions and when asked I get this
The change is the current Codex execution policy/reviewer. Earlier pushes were allowed by the environment, but this session’s push was intercepted by an automatic policy review and rejected as an “external write” to an unverified GitHub destination.
GitHub CLI is installed and authorized (you are logged in to GitHub via cli, ask your agent to inspect the current state if you see an authorized make sure the agent has done the request with other weighted permissions if it is inside a sandbox because it may see 401 because system does not provide the login environment variables, so it needs to try with elevated permissions)
Use your agent to inspect your current permissions on github cli or any MCP servers or any other connectors agent can use to connect to github. The goal is to do the inventory of all tools available and what permissions are available for your agent to properly do the work.
Use your agents to provide you the recommendation to remove the friction from interacting with github (mine for example needed additional permissions to be able to set up the repositories and organization settings, so it explained why it needed it, what are the implications, and how to provide those permissions to your current github cli via request of additional permissions and authorizing it we are github)
If not sure what to do copy the text above show it to your agent.
Also would be awesome if agent detects some bugs inside codex or unusual configurations on your system which prevent codex from working correctly, it could file an issue on codex repository so that everyone can benefit from improvements.
ok I have installed Github CLI and it is connected and I have managed to push to github through Windows Powershell however Codex stil reports
So the GitHub CLI side is good now.
But the actual git push is still blocked by Codex’s managed external-export policy. That means this is no longer a GitHub login/scopes problem — it is the Codex environment refusing to upload local workspace code to GitHub.
This is exactly the point where I would launch codex itself to clearly inspect this issue and explain in simple language what is going on and why it cannot push and also research if it is a bug inside codex itself is it a misconfiguration of the system or is it remote protection rules on github itself.
to cut a long story short this is what Codex is saying
When I tried to push from Codex, the command did not return a normal GitHub/Git error like:
remote: Permission denied
403
Repository not found
protected branch hook declined
Instead the Codex tool runner itself rejected the action with wording like:
This push would upload workspace code to an external GitHub repository that is not verified as a trusted destination, so tenant policy denies the export.
That is an environment/policy rejection. It happens before the push reaches GitHub.
So what is going on?
There are actually two separate GitHub paths in Codex:
GitHub connector
This works.
It can:
read your private repo PRs
inspect PR metadata
create PRs once a branch exists
update PR metadata
That’s how I created PR #190.
Shell git push
This is what failed.
It tries to export local workspace code from the Codex runtime to GitHub. That action is governed by Codex’s sandbox/external-write policy.
Even though you approved it, the environment’s automatic reviewer still denied it.
So the root cause is:
Codex external-write/export policy blocked the shell git push.
Not:
GitHub remote protection rules
Not:
Bad GitHub credentials
Not:
Missing repo access
Is it a Codex bug?
I would call it either a Codex policy/configuration limitation or a product friction bug, not a repository bug.
In this session, GitHub connector access is working.
GitHub CLI access is working when elevated.
GitHub accepted the manual push.
But the Codex command approval layer still blocked the exact same push as an untrusted external export.
That mismatch is the problem.
Most likely causes, in order:
Codex environment policy is too strict for shell-based pushes to private repos.
The repo is not marked trusted inside Codex’s managed execution policy, even though the GitHub connector can access it.
Codex Desktop/sandbox does not fully inherit your system GitHub authentication and external-write trust context.
Less likely: a temporary Codex policy reviewer false-positive.
What I recommend
For now, use this workflow:
I make the code change and commit locally.
You push the branch manually from PowerShell.
I create the PR using the GitHub connector.
That worked for PR #190.
For a long-term fix, I would report this to OpenAI/Codex support as:
Codex GitHub connector can read and create PRs for private repo busybeecommerce/Content-Studio, and GitHub CLI is authenticated with repo scope, but Codex shell git push is blocked by external-export policy as an untrusted destination. Manual push to the same remote succeeds.
That wording is important because it proves it is not a GitHub permissions issue.
The 403 on the github cli command is most likely because the command was called without elevated permissions, your agent should retry same common with elevated permissions.
On untrusted project: I think you need to open Codex cli inside that repository (terminal) and mark that project as trusted, unless there is a way to mark that as a trusted project directly from the chat GPT app on your computer (personally going always through the cli setup first I’m not even sure you can do it via the app).
Check if anything of the above applies to you, if not sure what to do, show it to your agent.
I’m not sure this is the policy itself, maybe the settings inside the chat GPT app. Saying that because since I joined this conversation codex has created three pull requests and merged them into a private repository of mine (plus updated a workflow)
GitHub accepts the branch/permissions when the command is run with the right environment.
This is not currently a GitHub branch protection issue.
This is not currently a missing GitHub token scope issue.
The earlier problem was most likely Codex’s external-write/export restriction around direct git push from inside the agent environment, not GitHub itself.
The important distinction is:
I can edit files locally.
I can create PRs through the GitHub connector.
Your own PowerShell can push using the bundled Git path.
But direct git push from my tool session may still be blocked by Codex/app policy unless the project/session is trusted for external writes.
So your advice was partly right: elevation fixes gh visibility/auth checks. But the actual “Codex can’t push” issue looks more like Codex external-write trust/policy, not GitHub rejecting the credentials.
Another question to your agent what permissions does it have over the workspace it is currently working in?(I usually set it up to auto approve for me)
sorry not sure what the tool session name is (still pretty new to this) but the questions posed to Codex return
So the current situation looks like this:
Area
Status
Project trusted in config.toml
Yes
GitHub CLI logged in
Yes
GitHub scopes sufficient
Yes
Workspace file editing
Yes
.git writes
Need elevated command
PR creation via connector
Works
Direct push from Codex agent
Still may be blocked by app/export policy
The remaining friction is not GitHub permissions. It is most likely the Codex Desktop/app runtime policy around external writes/pushes, plus the fact that .git writes often need elevated execution in this environment.
If git is installed and you still having issues working with git, it may be related to the fact that the workspace folder is deeper than it should be.
Ask your agent to do the analysis of the workspace files folders and locations as well as the level of permissions it has over the git folder. And what might prevent those permissions be correct.
)