Codex repeatedly creates or overwrites GitHub branches with orphan “Start repository” snapshot commits

Open 💬 0 comments Opened Aug 14, 2026 by sandoro85

What version of the Codex App are you using (From “About Codex” dialog)?

Codex cloud

What subscription do you have?

PRO

What platform is your computer?

_No response_

What issue are you seeing?

Codex appears to overwrite/create GitHub branches as orphan “Start repository” snapshot commits

Summary

Codex appears to create or overwrite GitHub branches with orphan/root snapshot commits titled Start repository, instead of preserving the real repository history.

This happened multiple times in a private GitHub repository with normal Git history. In one case, a branch that initially appeared to be based correctly on main later became an orphan/root branch with no merge base against origin/main.

This makes the resulting branch impossible to merge and potentially dangerous if it targets or overwrites an important branch.

I did not find an exact duplicate issue, although some existing issues look related to Codex branch/worktree/push handling.

Environment

Product: Codex with GitHub integration
Repository type: private GitHub repository
Repository state: normal Git history, not a newly initialized repository
Base branch: main
Task branch selected by user: a clean branch created from valid origin/main
Codex also created/published to an automatic codex/... branch

Exact repository name, full security log timestamps, and redacted Codex bootstrap logs can be shared privately with OpenAI maintainers if needed.

Expected behavior

When Codex runs against a selected GitHub branch, it should:

Fetch the selected branch from GitHub.
Preserve the branch’s existing Git history.
Create commits on top of the selected branch or base branch.
Never create an orphan/root commit unless explicitly requested.
Never replace a real branch history with a working-tree snapshot.
Never publish to a different automatic codex/... branch if the user selected a specific branch.
Never produce a branch with no merge base against main.

Actual behavior

Codex repeatedly produced or left behind branches where the only visible commit was:

Start repository

and:

git rev-list --parents -n 1 HEAD

returned only the HEAD SHA, with no parent commit.

This caused:

git merge-base --is-ancestor origin/main HEAD
echo $?

to return:

and:

git diff origin/main...HEAD --stat

to fail with:

fatal: origin/main...HEAD: no merge base

Known-good main

The repository’s valid main branch was restored and verified.

It is a merge commit with two parents. Example shape:

<known-good-main-sha> <parent-1-sha> <parent-2-sha>

So the repository is not supposed to be a single root snapshot.

Bad orphan/root commits observed

Several bad commits were observed as root/orphan snapshot commits.

Example shape:

<bad-orphan-sha> Start repository

For those commits:

git rev-list --parents -n 1 <bad-orphan-sha>

returned only:

<bad-orphan-sha>

with no parent hashes.

Example 1 — selected branch was already orphaned

In one run, Codex selected a branch that turned out to already point to an orphan/root snapshot commit.

Redacted Codex bootstrap pattern:

CODEX_GIT_CLONE_REF=<selected-branch>
git fetch origin --quiet --no-tags <selected-branch>
git switch -c work FETCH_HEAD
HEAD <bad-orphan-sha>
<bad-orphan-sha> Start repository

That explains this particular run, because the selected branch itself was already corrupted.

Example 2 — Codex-created branch initially valid, later became orphaned

A later Codex-created automatic branch initially appeared valid when checked through the GitHub API:

codex/<task-branch-name>
<valid-codex-commit-sha> <message>
parent: <known-good-main-sha>

So at that moment it was not a root commit and was based on valid main.

Later, after fetching the same branch locally:

git fetch origin
git checkout codex/<task-branch-name>

git status
git log --oneline --decorate -5
git rev-list --parents -n 1 HEAD
git merge-base --is-ancestor origin/main HEAD
echo $?
git diff origin/main...HEAD --stat

the output shape was:

Switched to a new branch 'codex/<task-branch-name>'
Your branch is up to date with 'origin/codex/<task-branch-name>'.

nothing to commit, working tree clean

<bad-orphan-short-sha> Start repository

<bad-orphan-full-sha>

1

fatal: origin/main...HEAD: no merge base

This indicates that the same Codex branch became an orphan/root snapshot branch after initially appearing valid.

Example 3 — important branch was previously moved to orphan snapshot commits

An important branch was also observed at different times pointing to orphan/root snapshot commits titled Start repository.

The branch was later manually restored to the known-good merge commit with two parents.

Branch protection/rulesets were added afterward to reduce risk.

Security log context

The GitHub security log showed a Codex Connector token regeneration shortly before one of the bad push sequences.

I am intentionally not including token IDs, hashed tokens, request IDs, IP addresses, or the full security log in this public issue.

I can provide redacted/private details to OpenAI maintainers if needed.

Impact

This is high risk because:

Codex branches become unmergeable due to no common history with main.
PR creation fails with “no history in common with main”.
A protected branch could be corrupted if protection is missing or misconfigured.
The resulting Git history is misleading because the commit message is simply Start repository.
Users lose time diagnosing branch ancestry instead of reviewing generated code.
Custom instructions inside Codex are not sufficient protection if the platform-level publish step overwrites refs.

User-side mitigations attempted

The following mitigations were attempted:

Restored main to the known-good merge commit.
Added GitHub branch protection/ruleset for main.
Created a clean task branch from valid origin/main.
Added Codex custom instructions requiring:

git status
git rev-parse HEAD
git rev-list --parents -n 1 HEAD
git log --oneline --decorate -10
ancestry checks against origin/main
stopping if HEAD is a root commit
Instructed Codex not to use automatic codex/... branches.
Deleted/recreated task branches.
Removed/reconnected GitHub token/connector.

Despite these mitigations, Codex still created or published to an automatic codex/... branch that later appeared as an orphan/root snapshot branch.

Related issues

I found related but not exact duplicate reports involving Codex branch/worktree/push behavior, for example:

Branch/workspace drift across Git branches
Remote push side effects before local tracking-ref failure
Git/worktree errors and orphaned Codex app-server processes

However, I did not find an exact duplicate where Codex overwrites or creates a GitHub branch as an orphan/root Start repository snapshot commit with no merge base against main.

Request

Please investigate whether Codex can incorrectly:

initialize or publish a repository snapshot as a root commit;
create an automatic codex/... branch from an internal workspace snapshot instead of the selected Git branch;
overwrite an existing remote branch with a root snapshot commit;
ignore or bypass selected branch/clone_ref expectations;
publish after passing earlier Git checks but before final branch ancestry verification.

Please also advise whether there is a known setting that prevents Codex from publishing automatic codex/... branches and forces it to work only on a user-selected branch.

Desired fix

Codex should refuse to publish if:

git rev-list --parents -n 1 HEAD

shows no parent commit, unless the repository itself is actually new and the selected branch is intentionally root.

Codex should also verify before pushing:

git merge-base --is-ancestor origin/main HEAD

or perform an equivalent base-branch ancestry check.

If there is no merge base, Codex should stop and report a checkout/publish error instead of pushing.

Additional notes

This repository is not newly initialized. It has valid Git history, and the restored valid main commit is a merge commit with two parents.

The repeated creation of orphan Start repository commits is unexpected and does not appear to be caused by normal user Git commands.

Why this does not look like a simple user configuration issue

One of the failed runs can be explained by the selected branch already being corrupted before Codex started. However, another case is harder to explain as user error:

A clean branch was created from valid origin/main.
The selected branch was verified to point to a known-good merge commit with real parent history.
Codex then created/published an automatic codex/... branch.
That codex/... branch initially appeared valid via the GitHub API and had the known-good main commit as its parent.
Later, fetching the same remote branch locally showed that it pointed to a root/orphan Start repository commit with no parent and no merge base with origin/main.

This sequence suggests that either Codex’s internal publish step, branch creation step, or workspace-to-remote synchronization step may be able to replace a valid branch state with a root snapshot commit.

The important point is not only that Codex can start from a bad branch. The more concerning behavior is that a branch that initially appeared valid later became an orphan/root branch after Codex activity.

This is why user-side custom instructions are not enough as a mitigation. The publish/sync layer should perform its own Git ancestry guard before updating any remote ref.

What steps can reproduce the bug?

The issue happened in a private GitHub repository with normal Git history. The repository was not newly initialized.

I do not have the Codex session ID, token limit usage, or context window usage available in the UI. I can provide private/redacted logs to OpenAI maintainers if there is a private channel for that.

Reproduction pattern observed

1. Start from a valid GitHub repository

The repository has a valid main branch with real history.

The restored known-good main commit is a merge commit with two parents:

git checkout main
git reset --hard origin/main
git rev-list --parents -n 1 HEAD

Expected shape:

<known-good-main-sha> <parent-1-sha> <parent-2-sha>

So this is not a new repository and not an intentional root commit.

2. Create a clean task branch from `origin/main`

git fetch origin
git checkout main
git reset --hard origin/main
git checkout -b fix/example-clean-task-branch
git push -u origin fix/example-clean-task-branch

Verify it is valid:

git rev-list --parents -n 1 HEAD
git merge-base --is-ancestor origin/main HEAD
echo $?

Expected:

<task-branch-head-sha> <parent-sha-or-parents>
0

3. Start a Codex task using that clean branch

In Codex, select the clean task branch as the branch/clone ref.

The prompt included custom Git safety instructions requiring Codex to stop if HEAD is a root commit, for example:

git status
git branch --show-current
git rev-parse HEAD
git rev-list --parents -n 1 HEAD
git log --oneline --decorate -10

The instructions also told Codex not to create or publish to automatic codex/... branches.

4. Codex created/published an automatic `codex/...` branch anyway

Codex created/published a branch similar to:

codex/<task-name>

Initially, the branch appeared valid via the GitHub API:

<codex-branch-commit-sha> <commit message>
parent: <known-good-main-sha>

So at that moment it was not a root commit and did have the known-good main commit as parent.

5. Later, fetching the same Codex branch locally showed it had become an orphan/root branch

After fetching the same remote branch locally:

git fetch origin
git checkout codex/<task-name>

git status
git log --oneline --decorate -5
git rev-list --parents -n 1 HEAD
git merge-base --is-ancestor origin/main HEAD
echo $?
git diff origin/main...HEAD --stat

Observed output shape:

Switched to a new branch 'codex/<task-name>'
Your branch is up to date with 'origin/codex/<task-name>'.

nothing to commit, working tree clean

<bad-orphan-short-sha> Start repository

<bad-orphan-full-sha>

1

fatal: origin/main...HEAD: no merge base

The important part is that:

git rev-list --parents -n 1 HEAD

returned only:

<bad-orphan-full-sha>

with no parent SHA, and the branch had no merge base with origin/main.

Concrete observed local output

Here is a redacted/safe version of the actual local check:

git fetch origin
git checkout codex/<task-name>

On branch codex/<task-name>
Your branch is up to date with 'origin/codex/<task-name>'.

nothing to commit, working tree clean

d70a5ec (HEAD -> codex/<task-name>, origin/codex/<task-name>) Start repository

d70a5ecc655a195059153b44edb4b41c2c33b11f

1

fatal: origin/main...HEAD: no merge base

This means the remote Codex branch pointed to an orphan/root Start repository commit.

Earlier related Codex bootstrap log pattern

In an earlier failed run, Codex selected a branch that was already orphaned. That case may be explained by the selected branch already being corrupted.

Redacted Codex bootstrap pattern:

CODEX_GIT_CLONE_REF=<selected-branch>
git fetch origin --quiet --no-tags <selected-branch>
git switch -c work FETCH_HEAD
HEAD <bad-orphan-sha>
<bad-orphan-sha> Start repository

However, the later case is more concerning because the Codex-created branch initially appeared valid and later became an orphan/root branch.

Why this seems like a Codex bug

This does not look like a normal user Git mistake because:

The base main branch had valid Git history.
A clean task branch was created from valid origin/main.
The Codex-created branch initially appeared to have the valid main commit as parent.
Later, the same remote branch pointed to a root/orphan Start repository commit.
That branch had no merge base with origin/main.
The prompt/custom instructions explicitly told Codex to stop on root commits and not to use automatic codex/... branches.

This suggests that Codex’s internal publish/sync layer may be able to create or overwrite a remote GitHub branch with a root snapshot commit after the model-level Git checks.

Minimal validation script for affected branches

This script detects the bad state:

#!/usr/bin/env bash
set -euo pipefail

BASE="${1:-origin/main}"
BRANCH="${2:-HEAD}"

echo "HEAD:"
git rev-parse "$BRANCH"

echo
echo "Parents:"
git rev-list --parents -n 1 "$BRANCH"

PARENT_COUNT="$(git rev-list --parents -n 1 "$BRANCH" | wc -w | tr -d ' ')"
if [ "$PARENT_COUNT" -le 1 ]; then
  echo "ERROR: branch head is a root/orphan commit"
  exit 1
fi

if ! git merge-base --is-ancestor "$BASE" "$BRANCH"; then
  echo "ERROR: branch has no valid ancestry from $BASE"
  git merge-base "$BASE" "$BRANCH" || true
  exit 1
fi

echo "OK: branch has parent history and is based on $BASE"

Expected behavior: Codex should perform an equivalent check before publishing any branch to GitHub. If a branch head has no parent and the selected repository is not a new repo, Codex should refuse to push.

What is the expected behavior?

Suggested platform-level guard

Before Codex updates any GitHub remote ref, it should perform a platform-level guard independent of model/custom instructions:

git rev-list --parents -n 1 HEAD

If the result contains only the HEAD SHA and no parent, Codex should refuse to publish unless the repository has been explicitly identified as a new repository with an intentional root commit.

For existing repositories, Codex should also verify that the branch has a merge base with the selected base branch:

git merge-base HEAD origin/main

or equivalent GitHub API ancestry logic.

If no merge base exists, Codex should refuse to push and show a clear error such as:

Refusing to publish: generated branch has no common history with the selected base branch.

This guard should run after any internal workspace/bootstrap/snapshot logic and immediately before updating the GitHub ref.

Additional information