GitHub @codex work task gets no tool to push back to existing PR despite write access

Open 💬 2 comments Opened Aug 13, 2026 by toumix-agents

Product

Codex Cloud / GitHub @codex mention workflow

Summary

A non-review @codex mention on an existing pull request started the expected Codex Cloud work task, checked out the correct repository and PR branch, edited and tested the code, and made a local commit. The task was not given any GitHub publishing tool, so it could not push the commit back to the existing PR branch despite the ChatGPT Codex Connector having write access.

This is not a dependency setup failure or a missing GitHub App installation.

Reproduction

Public pull request: https://github.com/discopy/discopy/pull/438

  1. Install the ChatGPT Codex Connector for discopy/discopy.
  2. Create a Codex Cloud environment for that repository.
  3. On the existing same-repository PR, comment:

``
@codex address the comments above
``

  1. After creating the environment, trigger it again:

``
done @codex try again
``

  1. Wait for the cloud task to finish.

Trigger: https://github.com/discopy/discopy/pull/438#issuecomment-5278877123

Result: https://github.com/discopy/discopy/pull/438#issuecomment-5279013264

Cloud task: https://chatgpt.com/s/cd_6a7d96c6688481919ffd773314ceb8cf

Actual behavior

The task:

  • checked out discopy/discopy on claude/issue-437-simplify-monoidal-layer;
  • edited five files;
  • ran the focused and full --skip-extra test suites successfully;
  • created local commit 2884cb1;
  • then reported that make_pr was unavailable, the checkout had no Git remote, and GitHub CLI was unauthenticated.

The task UI exposes only patch-copying actions. No commit reached the existing PR branch, whose head remained 8f11875f.

The task also tried to reason about creating another pull request even though it was launched from PR #438 and should have updated that PR's existing branch.

Verified permissions and repository state

At reproduction time:

  • the GitHub connector listed installations for toumix, toumix-agents, and the personal account discopy;
  • connector repository discovery returned discopy/discopy with push: true;
  • the public ChatGPT Codex Connector manifest requested contents: write and pull_requests: write;
  • the mentioning user toumix had repository write permission;
  • PR #438 used a same-repository head branch, not a fork;
  • no branch protection or repository ruleset blocked the head branch.

Reinstalling the app or adding a PAT to the cloud environment should not be necessary. Cloud secrets are unavailable during the agent phase, and the documented GitHub integration says a non-review @codex task can push a fix back to the PR branch when it has permission.

Expected behavior

A work task launched by a non-review @codex mention on an existing PR should receive the platform publishing capability needed to update that PR's current head branch.

It should:

  1. edit and validate the checkout;
  2. commit the completed change;
  3. push the commit to the existing PR branch through the connected GitHub installation;
  4. report the pushed commit accurately.

It should not require an authenticated gh CLI inside the isolated container, should not require a normal Git remote containing reusable credentials, and should not try to create a second PR.

If publication is intentionally disallowed, the task should fail before doing eleven minutes of mutation/testing and explain the exact authorization boundary rather than looking for a nonexistent make_pr tool.

Related

Related but distinct: #19520 reports fabricated successful make_pr narration. This report is the inverse failure: the task accurately admits that no publishing tool was exposed, leaving a real local commit stranded.

View original on GitHub ↗

2 Comments

datrinh · 6 days ago

Same/Similar issue here:

A Codex cloud task was provisioned with instructions requiring the agent to:

  1. commit changes on the current branch; and
  2. call the make_pr tool after committing.

However, the session does not expose a make_pr tool.

Repository diagnostics:

  • Working directory: /workspace/kolum
  • Git root: /workspace/kolum
  • Current branch: work
  • git remote -v: no output
  • git config --get-regexp '^remote\.': no output
  • GitHub CLI exists, but gh auth status says no GitHub hosts are authenticated
  • No GITHUB/GH repository or authentication environment hints were present

Expected behavior:

A task that requires make_pr should be provisioned with:

  • the make_pr callable tool;
  • repository/remote metadata identifying the target GitHub repository; and
  • whatever service authorization is required for PR creation.

Actual behavior:

The task requires make_pr, but the tool is absent, the checkout has no remote,
and GitHub CLI is unauthenticated. The agent therefore cannot comply with the
required PR workflow.

Please determine whether:

  • the GitHub connector failed to attach;
  • repository metadata was omitted during task provisioning;
  • make_pr was not registered for the session; or
  • a generic PR instruction was incorrectly applied to a task without GitHub access.
dwillz-cpu · 3 days ago

Independent reproduction from dwillz-cpu/commercial-os.

We are seeing the same Codex Cloud publication failure in a governed GitHub Actions orchestration flow.

Observed behavior:

  • A subscription-backed @codex task receives the exact governed task and runs in Codex Cloud.
  • Codex completes the implementation and tests successfully and produces a local commit/result.
  • The Cloud environment cannot publish the resulting builder branch/PR back to GitHub because no usable GitHub publication capability is exposed inside the task.
  • We therefore have to recover the exact Cloud result and publish the builder branch/PR manually before the rest of our GitHub-native validation pipeline can continue.

Our concrete reproduction used governing PR dwillz-cpu/commercial-os#65; the recovered builder result was published as PR #78 after the Cloud task itself could not publish it.

This is not a build/test failure. The implementation was successfully produced and independently revalidated after recovery. The missing capability is specifically the Cloud-to-GitHub publication step.

We also observe a separate outbound limitation in the subscription GitHub path: an @codex mention authored by github-actions[bot] does not reliably start the Codex Cloud task, while a user-authored @codex mention does. That is distinct from this issue, but together the two seams prevent a fully autonomous subscription-backed GitHub workflow.

Expected behavior for this issue: after a Codex Cloud task successfully builds/tests/commits work for an authorized repository task, the platform should be able to publish that exact result to the intended GitHub branch/PR through the connected GitHub installation, without requiring a PAT or separate OpenAI API billing.

Happy to provide exact task/run evidence if useful.