Next, set your OpenAI API key as an environment variable:
```bash
export OPENAI_API_KEY="your-api-key-here"
```
> **Note:** This command sets the key only for your current terminal session. To make it permanent, add the `export` line to your shell's configuration file (e.g., `~/.zshrc`).
<summary>OpenAI released a model called Codex in 2021 - is this related?</summary>
In 2021, OpenAI released Codex, an AI system designed to generate code from natural language prompts. That original Codex model was deprecated as of March 2023 and is separate from the CLI tool.
<summary>How do I stop Codex from touching my repo?</summary>
Codex always runs in a **sandbox first**. If a proposed command or file change looks suspicious you can simply answer **n** when prompted and nothing happens to your working tree.
Not directly. It requires [Windows Subsystem for Linux (WSL2)](https://learn.microsoft.com/en-us/windows/wsl/install) – Codex has been tested on macOS and Linux with Node≥22.
Any model available with [Responses API](https://platform.openai.com/docs/api-reference/responses). The default is `o4-mini`, but pass `--model gpt-4o` or set `model: gpt-4o` in your config file to override.
More broadly We welcome contributions – whether you are opening your very first pull request or you’re a seasoned maintainer. At the same time we care about reliability and long‑term maintainability, so the bar for merging code is intentionally **high**. The guidelines below spell out what “high‑quality” means in practice and should make the whole process transparent and friendly.
### Development workflow
- Create a _topic branch_ from `main`– e.g. `feat/interactive-prompt`.
- Keep your changes focused. Multiple unrelated fixes should be opened as separate PRs.
- Use `npm run test:watch` during development for super‑fast feedback.
- We use **Vitest** for unit tests, **ESLint** + **Prettier** for style, and **TypeScript** for type‑checking.
- Make sure all your commits are signed off with `git commit -s ...`, see [Developer Certificate of Origin (DCO)](#developer-certificate-of-origin-dco) for more details.
```bash
#Watch mode (tests rerun on change)
npm run test:watch
#Type‑check without emitting files
npm run typecheck
#Automatically fix lint + prettier issues
npm run lint:fix
npm run format:fix
```
### Writing high‑impact code changes
1.**Start with an issue.**
Open a new one or comment on an existing discussion so we can agree on the solution before code is written.
2.**Add or update tests.**
Every new feature or bug‑fix should come with test coverage that fails before your change and passes afterwards. 100% coverage is not required, but aim for meaningful assertions.
3.**Document behaviour.**
If your change affects user‑facing behaviour, update the README, inline help (`codex --help`), or relevant example projects.
4.**Keep commits atomic.**
Each commit should compile and the tests should pass. This makes reviews and potential rollbacks easier.
### Opening a pull request
- Fill in the PR template (or include similar information) –**What? Why? How?**
- Run **all** checks locally (`npm test && npm run lint && npm run typecheck`).
CI failures that could have been caught locally slow down the process.
- Make sure your branch is up‑to‑date with `main` and that you have resolved merge conflicts.
- Mark the PR as **Ready for review** only when you believe it is in a merge‑able state.
### Review process
1. One maintainer will be assigned as a primary reviewer.
2. We may ask for changes – please do not take this personally. We value the work, we just also value consistency and long‑term maintainability.
3. When there is consensus that the PR meets the bar, a maintainer will squash‑and‑merge.
### Community values
- **Be kind and inclusive.** Treat others with respect; we follow the [Contributor Covenant](https://www.contributor-covenant.org/).
- **Assume good intent.** Written communication is hard – err on the side of generosity.
- **Teach & learn.** If you spot something confusing, open an issue or PR with improvements.
### Getting help
If you run into problems setting up the project, would like feedback on an idea, or just want to say _hi_– please open a Discussion or jump into the relevant issue. We are happy to help.
Together we can make Codex CLI an incredible tool. **Happy hacking!** :rocket:
### Developer Certificate of Origin (DCO)
All commits **must** include a `Signed‑off‑by:` footer.
This one‑line self‑certification tells us you wrote the code and can contribute it under the repo’s license.
#### How to sign (recommended flow)
```bash
# squash your work into ONE signed commit
git reset --soft origin/main # stage all changes
git commit -s -m "Your concise message"
git push --force-with-lease # updates the PR
```
> We enforce **squash‑and‑merge only**, so a single signed commit is enough for the whole PR.
