65 Commits

• Show ChatGPT login URL during onboarding (#2028)

  ## Summary
  - display authentication URL in the ChatGPT sign-in screen while
  onboarding
  
  <img width="684" height="151" alt="image"
  src="https://github.com/user-attachments/assets/a8c32cb0-77f6-4a3f-ae3b-6695247c994d"
  />

  aibrahim-oai · 2025-08-09 01:30:34 +00:00
  4a916ba914
• Update README.md (#1989)

  Updates the README to clarify auth vs. api key behavior.

  Dylan · 2025-08-08 15:19:20 -07:00
  75febbdefa
• update readme (#1948)

  Co-authored-by: Alexander Embiricos <ae@openai.com>

  Ed Bayes · 2025-08-07 11:20:53 -07:00
  e07776ccc9
• fix: README ToC did not match contents (#1857)

  Similar to https://github.com/openai/codex/pull/1855, this got through.
  
  Fixed by running:
  
  ```
  python3 scripts/readme_toc.py --fix README.md
  ```

  Michael Bolin · 2025-08-05 11:48:28 -07:00
  0c5fa271bc
• fix: clean out some ASCII (#1856)

  Similar to https://github.com/openai/codex/pull/1855, this got through.
  
  Fixed by running:
  
  ```
  ./scripts/asciicheck.py README.md
  ```

  Michael Bolin · 2025-08-05 11:44:04 -07:00
  bd24bc320e
• Introduce --oss flag to use gpt-oss models (#1848)

  This adds support for easily running Codex backed by a local Ollama
  instance running our new open source models. See
  https://github.com/openai/gpt-oss for details.
  
  If you pass in `--oss` you'll be prompted to install/launch ollama, and
  it will automatically download the 20b model and attempt to use it.
  
  We'll likely want to expand this with some options later to make the
  experience smoother for users who can't run the 20b or want to run the
  120b.
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  easong-openai · 2025-08-05 11:31:11 -07:00
  9285350842
• Add login status command (#1716)

  Print the current login mode, sanitized key and return an appropriate
  status.

  pakrym-oai · 2025-07-30 14:09:26 -07:00
  301ec72107
• feat: add support for --sandbox flag (#1476)

  On a high-level, we try to design `config.toml` so that you don't have
  to "comment out a lot of stuff" when testing different options.
  
  Previously, defining a sandbox policy was somewhat at odds with this
  principle because you would define the policy as attributes of
  `[sandbox]` like so:
  
  ```toml
  [sandbox]
  mode = "workspace-write"
  writable_roots = [ "/tmp" ]
  ```
  
  but if you wanted to temporarily change to a read-only sandbox, you
  might feel compelled to modify your file to be:
  
  ```toml
  [sandbox]
  mode = "read-only"
  # mode = "workspace-write"
  # writable_roots = [ "/tmp" ]
  ```
  
  Technically, commenting out `writable_roots` would not be strictly
  necessary, as `mode = "read-only"` would ignore `writable_roots`, but
  it's still a reasonable thing to do to keep things tidy.
  
  Currently, the various values for `mode` do not support that many
  attributes, so this is not that hard to maintain, but one could imagine
  this becoming more complex in the future.
  
  In this PR, we change Codex CLI so that it no longer recognizes
  `[sandbox]`. Instead, it introduces a top-level option, `sandbox_mode`,
  and `[sandbox_workspace_write]` is used to further configure the sandbox
  when when `sandbox_mode = "workspace-write"` is used:
  
  ```toml
  sandbox_mode = "workspace-write"
  
  [sandbox_workspace_write]
  writable_roots = [ "/tmp" ]
  ```
  
  This feels a bit more future-proof in that it is less tedious to
  configure different sandboxes:
  
  ```toml
  sandbox_mode = "workspace-write"
  
  [sandbox_read_only]
  # read-only options here...
  
  [sandbox_workspace_write]
  writable_roots = [ "/tmp" ]
  
  [sandbox_danger_full_access]
  # danger-full-access options here...
  ```
  
  In this scheme, you never need to comment out the configuration for an
  individual sandbox type: you only need to redefine `sandbox_mode`.
  
  Relatedly, previous to this change, a user had to do `-c
  sandbox.mode=read-only` to change the mode on the command line. With
  this change, things are arguably a bit cleaner because the equivalent
  option is `-c sandbox_mode=read-only` (and now `-c
  sandbox_workspace_write=...` can be set separately).
  
  Though more importantly, we introduce the `-s/--sandbox` option to the
  CLI, which maps directly to `sandbox_mode` in `config.toml`, making
  config override behavior easier to reason about. Moreover, as you can
  see in the updates to the various Markdown files, it is much easier to
  explain how to configure sandboxing when things like `--sandbox
  read-only` can be used as an example.
  
  Relatedly, this cleanup also made it straightforward to add support for
  a `sandbox` option for Codex when used as an MCP server (see the changes
  to `mcp-server/src/codex_tool_config.rs`).
  
  Fixes https://github.com/openai/codex/issues/1248.

  Michael Bolin · 2025-07-07 22:31:30 -07:00
  e0c08cea4f
• docs: update README to include npm install again (#1475)

  v0.2.0 of https://www.npmjs.com/package/@openai/codex now runs the Rust
  CLI, so it makes sense to bring back the instructions to use `npm i -g
  @openai/codex`.
  
  In most places, I list `npm install` before `brew install` because I
  believe `npm` is more readily available, though I in the more detailed
  part of the documentation, I note that `brew install` will download
  fewer bytes, and in that sense, is preferred.

  Michael Bolin · 2025-07-07 17:44:26 -07:00
  0a44c42533
• docs: update documentation to reflect Rust CLI release (#1440)

  As promised on https://github.com/openai/codex/discussions/1405, we are
  making the first official release of the Rust CLI as v0.2.0. As part of
  this move, we are making it available in Homebrew:
  
  https://github.com/Homebrew/homebrew-core/pull/228615
  
  Ultimately, we also plan to continue to make the CLI available in npm,
  as well, though brew is a bit nicer in that `brew install` will download
  only the binary for your platform whereas an npm module is expected to
  contain the binaries for _all_ supported platforms, so it is a bit more
  heavyweight.
  
  A big part of this change is updating the root `README.md` to document
  the behavior of the Rust CLI, which differs in a number of ways from the
  TypeScript CLI. The existing `README.md` is moved to
  `codex-cli/README.md` as part of this PR, as it is still applicable to
  that folder.
  
  As this is still early days for the Rust CLI, I encourage folks to
  provide feedback on the command line flags and configuration options.

  Michael Bolin · 2025-07-01 15:00:31 -07:00
  abcca30d93
• add: responses api support for azure (#1321)

  - Use Responses API for Azure provider endpoints
  - Added a unit test to catch regression on the change from
  `/chat/completions` to `/responses`
  - Updated the default AOAI api version from `2025-03-01-preview` to
  `2025-04-01-preview` to avoid user/400 errors due to missing summary
  support in the March API version.
  - Changes have been tested locally on AOAI endpoints

  Eric Wright · 2025-06-22 18:01:13 -07:00
  ed5e848f3e
• restructure flake for codex-rs (#888)

  Right now since the repo is having two different implementations of
  codex, flake was updated to work with both typescript implementation and
  rust implementation

  Adeeb · 2025-05-13 13:08:42 -07:00
  ae809f3721
• chore: introduce new --native flag to Node module release process (#844)

  This PR introduces an optional build flag, `--native`, that will build a
  version of the Codex npm module that:
  
  - Includes both the Node.js and native Rust versions (for Mac and Linux)
  - Will run the native version if `CODEX_RUST=1` is set
  - Runs the TypeScript version otherwise
  
  Note this PR also updates the workflow URL to
  https://github.com/openai/codex/actions/runs/14872557396, as that is a
  build from today that includes everything up through
  https://github.com/openai/codex/pull/843.
  
  Test Plan:
  
  In `~/code/codex/codex-cli`, I ran:
  
  ```
  pnpm stage-release --native
  ```
  
  The end of the output was:
  
  ```
  Staged version 0.1.2505121317 for release in /var/folders/wm/f209bc1n2bd_r0jncn9s6j_00000gp/T/tmp.xd2p5ETYGN
  Test Node:
      node /var/folders/wm/f209bc1n2bd_r0jncn9s6j_00000gp/T/tmp.xd2p5ETYGN/bin/codex.js --help
  Test Rust:
      CODEX_RUST=1 node /var/folders/wm/f209bc1n2bd_r0jncn9s6j_00000gp/T/tmp.xd2p5ETYGN/bin/codex.js --help
  Next:  cd "/var/folders/wm/f209bc1n2bd_r0jncn9s6j_00000gp/T/tmp.xd2p5ETYGN" && npm publish --tag native
  ```
  
  I verified that running each of these commands ran the expected version
  of Codex.
  
  While here, I also added `bin` to the `files` list in `package.json`,
  which should have been done as part of
  https://github.com/openai/codex/pull/757, as that added new entries to
  `bin` that were matched by `.gitignore` but should have been included in
  a release.

  Michael Bolin · 2025-05-12 13:38:10 -07:00
  73fe1381aa
• feat: added arceeai as a provider (#818)

  - Added ArceeAI as a provider  - https://conductor.arcee.ai/v1
  - Compatible with ArceeAI SLMs (Virtuoso, Maestro)
  - Works with ArceeAI's Conductor auto‑router models (auto, auto‑tool),
  once #817 is merged

  Pranav · 2025-05-10 16:16:28 -07:00
  646e7e9c11
• fix: migrate to AGENTS.md (#764)

  Migrate from `codex.md` to `AGENTS.md`

  Fouad Matin · 2025-05-10 15:57:49 -07:00
  3104d81b7b
• Adds Azure OpenAI support (#769)

  ## Summary
  
  This PR introduces support for Azure OpenAI as a provider within the
  Codex CLI. Users can now configure the tool to leverage their Azure
  OpenAI deployments by specifying `"azure"` as the provider in
  `config.json` and setting the corresponding `AZURE_OPENAI_API_KEY` and
  `AZURE_OPENAI_API_VERSION` environment variables. This functionality is
  added alongside the existing provider options (OpenAI, OpenRouter,
  etc.).
  
  Related to #92
  
  **Note:** This PR is currently in **Draft** status because tests on the
  `main` branch are failing. It will be marked as ready for review once
  the `main` branch is stable and tests are passing.
  
  ---
  
  ## What’s Changed
  
  -   **Configuration (`config.ts`, `providers.ts`, `README.md`):**
  - Added `"azure"` to the supported `providers` list in `providers.ts`,
  specifying its name, default base URL structure, and environment
  variable key (`AZURE_OPENAI_API_KEY`).
  - Defined the `AZURE_OPENAI_API_VERSION` environment variable in
  `config.ts` with a default value (`2025-03-01-preview`).
      -   Updated `README.md` to:
          -   Include "azure" in the list of providers.
  - Add a configuration section for Azure OpenAI, detailing the required
  environment variables (`AZURE_OPENAI_API_KEY`,
  `AZURE_OPENAI_API_VERSION`) with examples.
  - **Client Instantiation (`terminal-chat.tsx`, `singlepass-cli-app.tsx`,
  `agent-loop.ts`, `compact-summary.ts`, `model-utils.ts`):**
  - Modified various components and utility functions where the OpenAI
  client is initialized.
  - Added conditional logic to check if the configured `provider` is
  `"azure"`.
  - If the provider is Azure, the `AzureOpenAI` client from the `openai`
  package is instantiated, using the configured `baseURL`, `apiKey` (from
  `AZURE_OPENAI_API_KEY`), and `apiVersion` (from
  `AZURE_OPENAI_API_VERSION`).
  - Otherwise, the standard `OpenAI` client is instantiated as before.
  -   **Dependencies:**
  - Relies on the `openai` package's built-in support for `AzureOpenAI`.
  No *new* external dependencies were added specifically for this Azure
  implementation beyond the `openai` package itself.
  
  ---
  
  ## How to Test
  
  *This has been tested locally and confirmed working with Azure OpenAI.*
  
  1.  **Configure `config.json`:**
  Ensure your `~/.codex/config.json` (or project-specific config) includes
  Azure and sets it as the active provider:
      ```json
      {
        "providers": {
          // ... other providers
          "azure": {
            "name": "AzureOpenAI",
  "baseURL": "https://YOUR_RESOURCE_NAME.openai.azure.com", // Replace
  with your Azure endpoint
            "envKey": "AZURE_OPENAI_API_KEY"
          }
        },
        "provider": "azure", // Set Azure as the active provider
        "model": "o4-mini" // Use your Azure deployment name here
        // ... other config settings
      }
      ```
  2.  **Set up Environment Variables:**
      ```bash
      # Set the API Key for your Azure OpenAI resource
      export AZURE_OPENAI_API_KEY="your-azure-api-key-here"
  
  # Set the API Version (Optional - defaults to `2025-03-01-preview` if
  not set)
  # Ensure this version is supported by your Azure deployment and endpoint
      export AZURE_OPENAI_API_VERSION="2025-03-01-preview"
      ```
  3.  **Get the Codex CLI by building from this PR branch:**
  Clone your fork, checkout this branch (`feat/azure-openai`), navigate to
  `codex-cli`, and build:
      ```bash
      # cd /path/to/your/fork/codex
      git checkout feat/azure-openai # Or your branch name
      cd codex-cli
      corepack enable
      pnpm install
      pnpm build
      ```
  4.  **Invoke Codex:**
  Run the locally built CLI using `node` from the `codex-cli` directory:
      ```bash
      node ./dist/cli.js "Explain the purpose of this PR"
      ```
  *(Alternatively, if you ran `pnpm link` after building, you can use
  `codex "Explain the purpose of this PR"` from anywhere)*.
  5. **Verify:** Confirm that the command executes successfully and
  interacts with your configured Azure OpenAI deployment.
  
  ---
  
  ## Tests
  
  - [x] Tested locally against an Azure OpenAI deployment using API Key
  authentication. Basic commands and interactions confirmed working.
  
  ---
  
  ## Checklist
  
  - [x] Added Azure provider details to configuration files
  (`providers.ts`, `config.ts`).
  - [x] Implemented conditional `AzureOpenAI` client initialization based
  on provider setting.
  -   [x] Ensured `apiVersion` is passed correctly to the Azure client.
  -   [x] Updated `README.md` with Azure OpenAI setup instructions.
  - [x] Manually tested core functionality against a live Azure OpenAI
  endpoint.
  - [x] Add/update automated tests for the Azure code path (pending `main`
  stability).
  
  cc @theabhinavdas @nikodem-wrona @fouad-openai @tibo-openai (adjust as
  needed)
  
  ---
  
  I have read the CLA Document and I hereby sign the CLA

  Govind Kamtamneni · 2025-05-09 18:11:32 -07:00
  7795272282
• Use "Title case" for ToC (#812)
  Andrey Mishchenko · 2025-05-05 08:49:42 -07:00
  7e97980cb4
• use "Title case" in README.md (#798)
  Andrey Mishchenko · 2025-05-03 10:17:44 -07:00
  4b61fb8bab
• chore: make build process a single script to run (#757)

  This introduces `./codex-cli/scripts/stage_release.sh`, which is a shell
  script that stages a release for the Node.js module in a temp directory.
  It updates the release to include these native binaries:
  
  ```
  bin/codex-linux-sandbox-arm64
  bin/codex-linux-sandbox-x64
  ```
  
  though this PR does not update Codex CLI to use them yet.
  
  When doing local development, run
  `./codex-cli/scripts/install_native_deps.sh` to install these in your
  own `bin/` folder.
  
  This PR also updates `README.md` to document the new workflow.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/757).
  * #763
  * __->__ #757

  Michael Bolin · 2025-05-01 08:36:07 -07:00
  3f5975ad5a
• fix: read version from package.json instead of modifying session.ts (#753)

  I am working to simplify the build process. As a first step, update
  `session.ts` so it reads the `version` from `package.json` at runtime so
  we no longer have to modify it during the build process. I want to get
  to a place where the build looks like:
  
  ```
  cd codex-cli
  pnpm i
  pnpm build
  RELEASE_DIR=$(mktemp -d)
  cp -r bin "$RELEASE_DIR/bin"
  cp -r dist "$RELEASE_DIR/dist"
  cp -r src "$RELEASE_DIR/src" # important if we want sourcemaps to continue to work
  cp ../README.md "$RELEASE_DIR"
  VERSION=$(printf '0.1.%d' $(date +%y%m%d%H%M))
  jq --arg version "$VERSION" '.version = $version' package.json > "$RELEASE_DIR/package.json"
  ```
  
  Then the contents of `$RELEASE_DIR` should be good to `npm publish`, no?

  Michael Bolin · 2025-04-30 11:03:10 -07:00
  84aaefa102
• docs: provider config (#653)

  close: #651
  
  Hi! @tibo-openai 👋 Could you share some great examples of
  `instructions.md` files? Thanks!
  
  ---------
  
  Co-authored-by: Thibault Sottiaux <tibo@openai.com>

  Luci · 2025-04-25 07:25:32 -07:00
  1ef8e8afd3
• update: readme (#630)

  - mention support for ZDR
  - codex open source fund

  Fouad Matin · 2025-04-24 14:05:26 -07:00
  bd1c3deed9
• feat: update README and config to support custom providers with API k… (#577)

  When using a non-built-in provider with the `--provider` option, users
  are prompted:
  
  ```
  Set the environment variable <provider>_API_KEY and re-run this command.
  You can create a <provider>_API_KEY in the <provider> dashboard.
  ```
  
  However, many users are confused because, even after correctly setting
  `<provider>_API_KEY`, authentication may still fail unless
  `OPENAI_API_KEY` is _also_ present in the environment. This is not
  intuitive and leads to ambiguity about which API key is actually
  required and used as a fallback, especially when using custom or
  third-party (non-listed) providers.
  
  Furthermore, the original README/documentation did not mention the
  requirement to set `<provider>_BASE_URL` for non-built-in providers,
  which is necessary for proper client behavior. This omission made the
  configuration process more difficult for users trying to integrate with
  custom endpoints.

  Asa · 2025-04-24 11:08:19 -07:00
  d1c0d5e683
• add instructions for connecting to a visual debugger under Contributing (#496)

  While here, I also moved the Nix stuff to the end of the
  **Contributing** section and replaced some examples with `npm` to use
  `pnpm`.

  Michael Bolin · 2025-04-22 09:43:10 -07:00
  94d5408875
• add check to ensure ToC in README.md matches headings in the file (#541)

  This introduces a Python script (written by Codex!) to verify that the
  table of contents in the root `README.md` matches the headings. Like
  `scripts/asciicheck.py` in https://github.com/openai/codex/pull/513, it
  reports differences by default (and exits non-zero if there are any) and
  also has a `--fix` option to synchronize the ToC with the headings.
  
  This will be enforced by CI and the changes to `README.md` in this PR
  were generated by the script, so you can see that our ToC was missing
  some entries prior to this PR.

  Michael Bolin · 2025-04-22 09:38:12 -07:00
  9b06fb48a7
• Enforce ASCII in README.md (#513)

  This all started because I was going to write a script to autogenerate
  the Table of Contents in the root `README.md`, but I noticed that the
  `href` for the "Why Codex?" heading was `#whycodex` instead of
  `#why-codex`. This piqued my curiosity and it turned out that the space
  in "Why Codex?" was not an ASCII space but **U+00A0**, a non-breaking
  space, and so GitHub ignored it when generating the `href` for the
  heading.
  
  This also meant that when I did a text search for `why codex` in the
  `README.md` in VS Code, the "Why Codex" heading did not match because of
  the presence of **U+00A0**.
  
  In short, these types of Unicode characters seem like a hazard, so I
  decided to introduce this script to flag them, and if desired, to
  replace them with "good enough" ASCII equivalents. For now, this only
  applies to the root `README.md` file, but I think we should ultimately
  apply this across our source code, as well, as we seem to have quite a
  lot of non-ASCII Unicode and it's probably going to cause `rg` to miss
  things.
  
  Contributions of this PR:
  
  * `./scripts/asciicheck.py`, which takes a list of filepaths and returns
  non-zero if any of them contain non-ASCII characters. (Currently, there
  is one exception for ✨ aka **U+2728**, though I would like to default to
  an empty allowlist and then require all exceptions to be specified as
  flags.)
  * A `--fix` option that will attempt to rewrite files with violations
  using a equivalents from a hardcoded substitution list.
  * An update to `ci.yml` to verify `./scripts/asciicheck.py README.md`
  succeeds.
  * A cleanup of `README.md` using the `--fix` option as well as some
  editorial decisions on my part.
  * I tried to update the `href`s in the Table of Contents to reflect the
  changes in the heading titles. (TIL that if a heading has a character
  like `&` surrounded by spaces, it becomes `--` in the generated `href`.)

  Michael Bolin · 2025-04-22 10:07:40 -04:00
  c00ae2dcc1
• update: readme (#491)
  Fouad Matin · 2025-04-21 15:06:03 -07:00
  0e9d75657b
• docs: Add note about non-openai providers; add --provider cli flag to the help (#484)
  Daniel Nakov · 2025-04-21 14:53:09 -07:00
  e7a3eec942
• revert #386 due to unsafe shell command parsing (#478)

  Reverts https://github.com/openai/codex/pull/386 because:
  
  * The parsing logic for shell commands was unsafe (`split(/\s+/)`
  instead of something like `shell-quote`)
  * We have a different plan for supporting auto-approved commands.

  Michael Bolin · 2025-04-21 12:52:11 -04:00
  d36d295a1a
• feat: read approvalMode from config file (#298)

  This PR implements support for reading the approvalMode setting from the
  user's config file (`~/.codex/config.json` or `~/.codex/config.yaml`),
  allowing users to set a persistent default approval mode without needing
  to specify command-line flags for each session.
  
  Changes:
  - Added approvalMode to the AppConfig type in config.ts
  - Updated loadConfig() to read the approval mode from the config file
  - Modified saveConfig() to persist the approval mode setting
  - Updated CLI logic to respect the config-defined approval mode (while
  maintaining CLI flag priority)
  - Added comprehensive tests for approval mode config functionality
  - Updated README to document the new config option in both YAML and JSON
  formats
  - additions to `.gitignore` for other CLI tools
  
  Motivation:
  As a user who regularly works with CLI-tools, I found it odd to have to
  alias this with the command flags I wanted when `approvalMode` simply
  wasn't being parsed even though it was an optional prop in `config.ts`.
  This change allows me (and other users) to set the preference once in
  the config file, streamlining daily usage while maintaining the ability
  to override via command-line flags when needed.
  
  Testing:
  I've added a new test case loads and saves approvalMode correctly that
  verifies:
  - Reading the approvalMode from the config file works correctly
  - Saving the approvalMode to the config file works as expected
  - The value persists through load/save operations
  
  All tests related to the implementation are passing.

  John Gardner · 2025-04-19 07:25:25 -07:00
  965420cfc5
• feat: add user-defined safe commands configuration and approval logic #380 (#386)

  This pull request adds a feature that allows users to configure
  auto-approved commands via a `safeCommands` array in the configuration
  file.
  
  ## Related Issue
  #380 
  
  ## Changes
  - Added loading and validation of the `safeCommands` array in
  `src/utils/config.ts`
  - Implemented auto-approval logic for commands matching `safeCommands`
  prefixes in `src/approvals.ts`
  - Added test cases in `src/tests/approvals.test.ts` to verify
  `safeCommands` behavior
  - Updated documentation with examples and explanations of the
  configuration

  autotaker · 2025-04-18 22:35:32 -07:00
  ca7ab76569
• docs: update README to use pnpm commands (#390)

  Since we migrated to `pnpm` in #287, this updates the README to reflect
  that change.
  Just a small cleanup to align the commands with the current setup.

  Benny Yen · 2025-04-18 22:16:13 -07:00
  fd6f6c51c0
• feat: add Nix flake for reproducible development environments (#225)

  This PR introduces a Nix flake configuration to enable reproducible
  development environments:
  
  - Adds flake.nix defining a devShell with necessary dependencies.
  - Updates README.md with usage instructions for `nix develop`.
  - Ensures CI compatibility with Nix for consistent builds.

  Gerred Dillon · 2025-04-17 22:52:54 -07:00
  41b8fe08dd
• fix(docs): Fix the <details> misplace in README.md (#294)

  #291 Fixes
  
  Fix the misplace of `<details>`
  
  **BEFORE**
  <img width="876" alt="image"
  src="https://github.com/user-attachments/assets/254de872-d08d-4bca-875a-36bf793e3cd3"
  />
  
  
  
  **AFTER**
  <img width="600" alt="image"
  src="https://github.com/user-attachments/assets/337e3759-0c7b-4660-a9a6-c688cacf4c9d"
  />

  gambhir ⚡ · 2025-04-17 20:26:09 -07:00
  3e517201cd
• feat(bin): support bun fallback runtime for codex CLI (#282)

  This PR adds a shell wrapper in `codex-cli/bin/codex` to detect node or
  bun as the runtime.
  
  It updates:
  - `package.json` bin entry
  - published files list to include bin/
  - README install instructions to include `bun install -g @openai/codex`

  Sam Verhasselt · 2025-04-17 17:32:19 -07:00
  6ee589cd1a
• add(.github): issue templates (#283)

  Add issue templates for:
  - Bug report
  - Docs issue

  Fouad Matin · 2025-04-17 17:19:30 -07:00
  e80d1df172
• feat: add notifications for MacOS using Applescript (#160)

  yolo'ed it with codex. Let me know if this looks good to you.
  
  https://github.com/openai/codex/issues/148
  
  tested with:
  ```
  npm run build:dev
  ```
  
  <img width="377" alt="Screenshot 2025-04-16 at 18 12 01"
  src="https://github.com/user-attachments/assets/79aa799b-b0b9-479d-84f1-bfb83d34bfb9"
  />

  kchro3 · 2025-04-17 16:19:26 -07:00
  0a2e416b7a
• fix: npm run format:fix in root (#268)

  stupid minor. unless you have main branch push setup to fix this
  yourself, here you go
  
  Latest commit is failing the format step in repo root
  
  https://github.com/openai/codex/actions/runs/14524272942/job/40752229698

  Jon Church · 2025-04-17 13:39:50 -07:00
  d5eed65963
• docs: mention dotenv support in Quickstart (#262)

  Add a note in Quickstart that you can drop your API key into a `.env`
  file
  (since dotenv support was introduced in 40266be #122).
  
  ✅ Ran `npm test && npm run lint && npm run typecheck` locally
  
  I have read the CLA Document and I hereby sign the CLA
  
  Signed-off-by: Dan Lewis <dglewi@gmail.com>

  Dan Lewis · 2025-04-17 13:29:57 -07:00
  603def0c7a
• docs: add tracing instructions to README (#257)

  **What**?
  Add a `Tracing / Verbose Logging` section to the README
  
  **Why**?
  Enable easier troubleshooting by logging full API requests, responses,
  and prompt details used during code generation.
  
  **How**?
  
  Inserted the new section between `Non‑interactive / CI mode` and `FAQ`.

  Uladzimir Yancharuk · 2025-04-17 11:44:02 -07:00
  701b6736ff
• docs: clarify sandboxing situation on Linux (#103)

  There doesn't appear to actually be any sandboxing on Linux. Correct the
  README.
  
  Signed-off-by: Christopher Cooper <christopher@cg505.com>

  Christopher Cooper · 2025-04-17 08:15:39 -07:00
  f9c15523e7
• Feat/add husky (#223)

  # Add Husky and lint-staged for automated code quality checks
  
  ## Description
  This PR adds Husky Git hooks and lint-staged to automate code quality
  checks during the development workflow.
  
  ## Features Added
  - Pre-commit hook that runs lint-staged to check files before committing
  - Pre-push hook that runs tests and type checking before pushing
  - Configuration for lint-staged to format and lint different file types
  - Documentation explaining the Husky setup and usage
  - Updated README.md with information about Git hooks
  
  ## Benefits
  - Ensures consistent code style across the project
  - Prevents pushing code with failing tests or type errors
  - Reduces the need for style-related code review comments
  - Improves overall code quality
  
  ## Implementation Details
  - Added Husky and lint-staged as dev dependencies
  - Created pre-commit and pre-push hooks
  - Added configuration for lint-staged
  - Added documentation in HUSKY.md
  - Updated README.md with a new section on Git hooks
  
  ## Testing
  The hooks have been tested locally and work as expected:
  - Pre-commit hook runs ESLint and Prettier on staged files
  - Pre-push hook runs tests and type checking
  
  I have read the CLA Document and I hereby sign the CLA
  
  ---------
  
  Signed-off-by: Alpha Diop <alphakhoss@gmail.com>

  Alpha Diop · 2025-04-17 07:18:43 -07:00
  639c67b909
• docs: add ZDR org limitation to README (#234)

  **What?**
  Add a section to the README documenting the current limitation for Codex
  with Zero Data Retention (ZDR) organizations.
  
  **Why?**
  Users from ZDR organizations encounter errors due to the Responses API’s
  requirement for `store:true`, which is incompatible with ZDR policies.
  See #106 for more info.
  
  **How?**
  - Added a new section in the README, after FAQ and before Funding. 
  - Explained the error message and reason.
  - Linked to documentation as linked in the issue.

  Akshey D · 2025-04-17 07:09:23 -07:00
  842de865cd
• (fix) move funding section before contrib section (#184)

  Signed-off-by: Thibault Sottiaux <tibo@openai.com>

  Thibault Sottiaux · 2025-04-16 21:01:03 -07:00
  4da38e7f01
• document Codex open source fund (#162)

  I added a section about the Codex Open Source Fund to the README to
  reach more developers.

  Mert Erbak · 2025-04-16 18:34:55 -07:00
  057f113c6d
• fmt (#161)

  Signed-off-by: Thibault Sottiaux <tibo@openai.com>

  Thibault Sottiaux · 2025-04-16 18:15:22 -07:00
  2aa8ae4167
• w

  Signed-off-by: Thibault Sottiaux <tibo@openai.com>

  Thibault Sottiaux · 2025-04-16 18:10:47 -07:00
  9172840647
• minor change in description of Build from source in README.md (#149)

  Separated the `node ./dist/cli.js --help ` and `node ./dist/cli.js `.
  The comment suggested `node ./dist/cli.js --help ` was to run the
  locally-built CLI but in fact it shows the usage an options. It is a
  minor change and clarifies the flow for new developers.

  Mehmet Vecdi Gönül · 2025-04-16 17:07:44 -07:00
  b8aea2340d
• Fix markdown table in README (#144)

  Before:
  
  <img width="909" alt="image"
  src="https://github.com/user-attachments/assets/8de0d798-5587-407a-9196-bda3e26c1331"
  />
  
  After:
  
  <img width="945" alt="image"
  src="https://github.com/user-attachments/assets/90454694-2f26-49b1-8c4b-e017237797ca"
  />

  Ashwin Ramaswami · 2025-04-16 17:01:45 -07:00
  099224e313
• feat: add shell completion subcommand (#138)

  Why
  ---
  Improves the usability of the `codex` CLI by adding shell completion for
  file paths. This allows users to quickly complete file arguments using
  tab completion in bash, zsh, and fish shells. Enable via `eval "$(codex
  completion <shell>)"`.

  Tomas Cupr · 2025-04-16 16:34:44 -07:00
  33d0d73b82