Target branch changes - Codex fails

Codex
1

So I’ve started using Codex yesterday. Love it.
Asked for doing like 3-5 tasks in pararell. Works great.
Then created one PR in one that was to conflict with another task, should be fine right?
But once I’ve merged one and the other one not yet having PR started to fail.
It is not rate limitting as I’ve wated 24 hours almost and it still persists. My 3 tasks are unsalvagable now I guess, cause I can’t create PRs from them. But they fail all the time.
I can easly create new tasks thou, so there is no rate limit.

Is this expected to fail right now? If main branch changes in the background?
Do I need to work on one task at the same time or just merge them all together when all done?

Ah I was asking for changes via comments on code and by prompt.

Update:

actually ANY changes on target branches fails other tasks. Not only conflicting. I again accepted one PR and merged and other task was waiting for my input. Added comments in code and asked for reviewing them.
And it fails, constantly fails.

2 Likes
2

Hola @TheCodexCoder

What you’re seeing lines up with how Codex cloud tasks work today plus a rough edge/bug in “long-lived parallel tasks.”

What’s actually happening

A Codex cloud task runs in its own container and checks out your repo at the branch (or commit SHA) you selected at task start. It’s basically a snapshot.

Two consequences:

  1. Tasks don’t automatically “track” new commits on main while they’re waiting for your next prompt. They’re still sitting on the old snapshot unless something explicitly refreshes them.

  2. In some setups, the environment won’t even have a normal origin remote available for git fetch/pull, which makes “just rebase onto the updated base branch” impossible inside that task.

So if you merge anything into the base branch while other tasks are still alive, those tasks can end up in a stale state where follow-ups / PR creation start failing. There’s even a reported bug/behavior around parallel tasks not updating their context when other branches/versions change after the task starts.

Is it “expected”? The snapshot aspect is expected; the permanent failure is not ideal and appears to be a known pain point (multiple reports).

How to salvage your 3 “unsalvageable” tasks (you can rescue the work)

Even if Codex won’t create PRs from those tasks anymore, you can still extract the diff and ship it.

Option A (fastest): Copy the patch → apply locally → PR manually

  1. Open the task → find the diff/changes view → use Copy patch / Copy git apply (wording varies by surface; Codex added patch-copy affordances).

  2. In your local repo:

git checkout main
git pull
git checkout -b codex/rescue-task-1

# If you saved it to a file:
git apply /path/to/codex.patch

# Or if you copied patch text:
git apply -
# (paste the patch, then Ctrl+D)
  1. Run tests, commit, push, open PR.

This bypasses the broken “Create PR” flow inside the stale task.

Option B: Rehydrate into a fresh task (still let Codex open the PR)

  1. Create a new Codex task on latest main.

  2. Paste the patch into the prompt: “Apply this patch exactly, run tests, then create a PR.”

  3. Now PR creation usually works because the task started from the current base.

How to prevent it going forward (parallel work without self-sabotage)

Workflow 1: Freeze the base branch while tasks run (simple)

  • Start 3–5 tasks in parallel

  • Do not merge anything into main until each task has opened its PR (or at least pushed its branch)

  • Then merge/rebase the PRs as needed

Workflow 2: Use an integration branch (best for teams)

  • Create codex/integration-YYYYMMDD from main

  • Point all Codex tasks at that integration branch

  • Merge Codex PRs into the integration branch

  • When ready, merge integration → main

This keeps main moving while the “Codex base” stays stable for the duration.

Workflow 3: Pin tasks to a commit SHA (if your UI lets you)

Docs say the task can check out a branch or commit SHA at start.
If you pin to a SHA, you’re explicitly saying “this task’s base won’t move,” which avoids surprise drift. You’ll still reconcile later, but you control when.

If you want to try “fixing” the failing tasks (sometimes works)

These won’t always recover the stuck tasks, but they’re worth a shot:

  1. Reset the environment cache (tasks can resume from cached containers; caches exist up to ~12 hours and can get incompatible).

  2. Reconnect GitHub in Codex (some “Failed to create PR” waves were just auth disconnects).

The blunt takeaway

  • Parallel tasks are fine, as long as the base branch they’re targeting doesn’t change mid-flight.

  • If you need main to keep moving, use an integration branch.

  • When a task gets stuck: copy patch → apply locally → PR is the reliable escape hatch.