Menu
Pushing GitHub Actions changes, resolving push rejection, requesting upload exceptions.
Create and scaffold plugin directories for Codex with a required `.codex-plugin/plugin.json`, optional plugin folders/files, valid manifest defaults, and personal-marketplace entries by default. Use when Codex needs to create a new personal plugin, add optional plugin structure, generate or update marketplace entries for plugin ordering and availability metadata, or update an existing local plugin during development with the CLI-driven cachebuster and reinstall flow.
Choose Rust types for operating system paths across the Codex repository. Use when defining new path-bearing types or explicitly migrating existing ones.
How to run tests using remote executor.
Babysit a GitHub pull request after creation by continuously polling review comments, CI checks/workflow runs, and mergeability state until the PR is merged/closed or user help is required. Diagnose failures, retry likely flaky failures up to 3 times, auto-fix/push branch-related issues when appropriate, and keep watching open PRs so fresh review feedback is surfaced promptly. Use when the user asks Codex to monitor a PR, watch CI, handle review comments, or keep an eye on failures and feedback on an open PR.
Update the title and body of one or more pull requests.
Use when the user asks how to build with OpenAI products or APIs, asks about Codex itself or choosing Codex surfaces, needs up-to-date official documentation with citations, help choosing the latest model for a use case, or model upgrade and prompt-upgrade guidance; use OpenAI docs MCP tools for non-Codex docs questions, use the Codex manual helper first for broad Codex self-knowledge, and restrict fallback browsing to official OpenAI domains.
| name | pushing-ci-changes |
| description | Pushing GitHub Actions changes, resolving push rejection, requesting upload exceptions. |
The Codex repository prevents anyone from uploading changes to its CI configuration unless they've been granted a temporary role.
In order to push changes to .github/**/*.yml and related files you'll need the user to read
go/workflow-approvals and request an approval through that flow. It is not possible for you to
make progress by requesting an exemption yourself.
If you know you're about to push changes that would fail due to these restrictions you should still try to push anyways to confirm the user's account doesn't already have the necessary approval.
If you encounter a failed push due to these restrictions, share the go/workflow-approvals link with the user and ask them to return control to you once the approval has propagated to GitHub.
