Updating Codex Contribution Guidelines

[etraut-openai]

Over the past year, the way code is written has changed dramatically. AI coding tools like Codex have made it cheap and fast to generate large volumes of code. While this has been a huge productivity win, it has also put real strain on traditional open-source contribution models.

In the Codex project, we currently receive many dozens of community pull requests every week. While we deeply appreciate the time and enthusiasm behind these contributions, we’ve found that reviewing, correcting, and integrating external PRs often takes more effort than implementing the same fixes directly. In many cases, PRs focus on low-priority issues or are difficult to evaluate without additional architectural context or insight into the project’s roadmap.

As a result, community PRs have increasingly become a bottleneck rather than a force multiplier.

What’s changing?

We are updating our contribution guidelines to move to an invitation-only model for code contributions.

• We no longer accept unsolicited pull requests.
• As before, feature ideas and behavior changes should be proposed through issues and discussions.
• Bugs should still be reported via issues, and we strongly encourage contributors to share analysis, reproduction details, and proposed approaches in the issue thread.

The Codex team may invite external contributors to submit a PR after a discussion when the problem is well understood and the issue is high-impact and high-priority.

Why this approach?

In an AI-accelerated world, code itself is no longer the scarce resource. Understanding the problem, identifying the right solution, and making good prioritization decisions are the hard parts. Those are the areas where community input is most valuable — and where it scales.

We’ve found that engaging contributors earlier, through discussion and analysis rather than code diffs, leads to better outcomes for everyone. Once the right solution is clear, the implementation is usually straightforward.

How you can contribute and make a real impact?

Community contributions remain incredibly important to Codex. The highest-leverage ways to help today include:

• High-quality bug reports with clear repro steps
• Root-cause analysis and design discussion in issues
• Thoughtful feature requests grounded in real use cases
• Feedback on workflows, UX, and overall direction
• Signals that help us prioritize what matters most

These contributions directly shape the project and help us focus our time on the work that has the greatest impact.
We know this is a shift from traditional OSS norms, and we don’t take it lightly. Our goal is to keep Codex moving fast while remaining open, transparent, and community-driven—just in a way that fits the realities of modern AI-powered development.

Thanks, as always, for your engagement and support.

[GuangmingLuo]

“As before, feature ideas and behavior changes should be proposed through issues and discussions.”
-> Totally agree ! And it has never been changed. It’s rude and unwelcome to submit a PR directly without first discussing and confirming it via an Issue or a Discussion, especially for first-time contributors.

[Bad3r]

TLDR: because of AI; which we helped create and popularize and advertise as a good tool for coding, we don't accept contributions. How ironic.

[pkkkkkkkkkkkkk]

Maybe because they can use ai themself instead of your poorly written code by a worse model 🤔

[Bad3r]

Maybe because they can use ai themself instead of your poorly written code by a worse model 🤔

how does the bottom of boots tastes like? You sound like an expert.

[448523760]

Hi,

I would like to ask, if the changes are related to documentation, does the Codex team still open for such PRs?

Is it necessary to create an issue beforehand, or can I submit the PR directly? As you know, it's often difficult for documentation to keep up with the code, and it tends to lag behind.

I'm curious about the Codex team's strategy for maintaining documentation—do they plan to manage it internally, or do they welcome contributions from the community?

[etraut-openai]

Documentation for Codex is published here. The source for this documentation is in a private repo, so it can be updated only by OpenAI employees. Many of the updates are automated by Codex. The code base is changing so quickly that it would be almost impossible to keep up with documentation changes if we had to do it manually.

If you see a bug in the documentation or want to suggest an improvement, please file a bug report in the issue tracker.

[unitof]

Could you clarify which issue tracker for documentation bug reports? This repo's Issues?

[etraut-openai]

Yes, this repo's issues.

[pavan-sh]

This makes sense. In 2026, implementation is cheap; reviewer attention + roadmap context isn’t.

[dagelf]

It's good that you're communicating up front.

My 5c: Sometimes a pull request/fix IS the most concise description and review of the problem.

Now even more so.

Problem is that many people who submit bug reports are not technically proficient enough to understand what they're seeing.

The old regime works even better now - an LLM can explain the implications, and they can work through it, iterate and likely figure out the core of their issue - even iterate using your own models, until their issue is fixed.

Arguably saves you more time than trying to understand bug reports. The regime of accepting PR's that address bug reports directly seems like a good way to accept PRs - and to train your models better on bug reports.

Then there's also the community/contributor part... also arguably even more important to grow and conserve because that window is probably going to close naturally, why rush it?

[dagelf]

What I mean is that the only PR's that will eventually come here are the ones where GPT can not figure it out anyways, or gets stuck in being too pedantic, or some issue it can't yet iterate on fast enough.