openai/codex: Lightweight coding agent that runs in your terminal

Lightweight coding agent that runs in your terminal

npm i -g @openai/codex

Install globally:

npm install -g @openai/codex

Run interactively:

Or, run with a prompt as input (and optionally in Full Auto mode):

codex "explain this codebase to me"

codex --approval-mode full-auto "create the fanciest todo-list app"

That’s it – Codex will scaffold a file, run it inside a sandbox, install any
missing dependencies, and show you the live result. Approve the changes and
they’ll be committed to your working directory.

Codex CLI is built for developers who already live in the terminal and want
ChatGPT‑level reasoning plus the power to actually run code, manipulate
files, and iterate – all under version control. In short, it’s chat‑driven
development that understands and executes your repo.

• Zero setup — bring your OpenAI API key and it just works!
• Full auto-approval, while safe + secure by running network-disabled and directory-sandboxed
• Multimodal — pass in screenshots or diagrams to implement features ✨

And it’s fully open-source so you can see and contribute to how it develops!

Codex lets you decide how much autonomy the agent receives and auto-approval policy via the
--approval-mode flag (or the interactive onboarding prompt):

In Full Auto every command is run network‑disabled and confined to the
current working directory (plus temporary files) for defense‑in‑depth. Codex
will also show a warning/confirmation if you start in auto‑edit or
full‑auto while the directory is not tracked by Git, so you always have a
safety net.

Coming soon: you’ll be able to whitelist specific commands to auto‑execute with
the network enabled, once we’re confident in additional safeguards.

The hardening mechanism Codex uses depends on your OS:

• macOS 12+ – commands are wrapped with Apple Seatbelt (sandbox-exec).

  • Everything is placed in a read‑only jail except for a small set of
    writable roots ($PWD, $TMPDIR, ~/.codex, etc.).
  • Outbound network is fully blocked by default – even if a child process
    tries to curl somewhere it will fail.

• Linux – we recommend using Docker for sandboxing, where Codex launches itself inside a minimal
  container image and mounts your repo read/write at the same path. A
  custom iptables/ipset firewall script denies all egress except the
  OpenAI API. This gives you deterministic, reproducible runs without needing
  root on the host. You can read more in run_in_container.sh

Both approaches are transparent to everyday usage – you still run codex from your repo root and approve/reject steps as usual.

Never run sudo npm install -g; fix npm permissions instead.

Key flags: --model/-m, --approval-mode/-a, and --quiet/-q.

Codex merges Markdown instructions in this order:

1. ~/.codex/instructions.md – personal global guidance
2. codex.md at repo root – shared project notes
3. codex.md in cwd – sub‑package specifics

Disable with --no-project-doc or CODEX_DISABLE_PROJECT_DOC=1.

Run Codex head‑less in pipelines. Example GitHub Action step:

- name: Update changelog via Codex
  run: |
    npm install -g @openai/codex
    export OPENAI_API_KEY="${{ secrets.OPENAI_KEY }}"
    codex -a auto-edit --quiet "update CHANGELOG for next release"

Set CODEX_QUIET_MODE=1 to silence interactive UI noise.

Below are a few bite‑size examples you can copy‑paste. Replace the text in quotes with your own task.

npm install -g @openai/codex
# or
yarn global add @openai/codex

# Clone the repository and navigate to the CLI package
git clone https://github.com/openai/codex.git
cd codex/codex-cli

# Install dependencies and build
npm install
npm run build

# Run the locally‑built CLI directly
node ./dist/cli.js --help

# Or link the command globally for convenience
npm link

Codex looks for config files in ~/.codex/.

# ~/.codex/config.yaml
model: o4-mini # Default model
fullAutoErrorMode: ask-user # or ignore-and-continue

You can also define custom instructions:

# ~/.codex/instructions.md
- Always respond with emojis
- Only use git commands if I explicitly mention you should

This project is under active development and the code will likely change pretty siginificantly. We’ll update this message once that’s complete!

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.

• 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) for more details.

# 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

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.

• 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.

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.

• good first issue – great for newcomers, usually well‑scoped and low risk.
• help wanted – higher impact, still looking for outside contributors.
• discussion – exploring the problem/solution space; code contributions are discouraged until the direction is clear.

• Be kind and inclusive. Treat others with respect; we follow the Contributor Covenant.
• 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.

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! 🚀

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.

# 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.

The DCO check blocks merges until every commit in the PR carries the footer (with squash this is just the one).

Have you discovered a vulnerability or have concerns about model output? Please e‑mail security@openai.com and we will respond promptly.

This repository is licensed under the Apache-2.0 License.