codex

Add static mcp callback uri support (#8971 )

Currently the callback URI for MCP authentication is dynamically
generated. More specifically, the callback URI is dynamic because the
port part of it is randomly chosen by the OS. This is not ideal as
callback URIs are recommended to be static and many authorization
servers do not support dynamic callback URIs.

This PR fixes that issue by exposing a new config option named
`mcp_oauth_callback_port`. When it is set, the callback URI is
constructed using this port rather than a random one chosen by the OS,
thereby making callback URI static.

Related issue: https://github.com/openai/codex/issues/8827

WhammyLeaf · 2026-01-12 16:57:04 +00:00

d5562983d9

feat: add close tool implementation for collab (#9090 )

Pretty straight forward. A known follow-up will be to drop it from the
AgentControl

jif-oai · 2026-01-12 13:21:46 +00:00

9659583559

feat: add wait tool implementation for collab (#9088 )

Add implementation for the `wait` tool.

For this we consider all status different from `PendingInit` and
`Running` as terminal. The `wait` tool call will return either after a
given timeout or when the tool reaches a non-terminal status.

A few points to note:
* The usage of a channel is preferred to prevent some races (just
looping on `get_status()` could "miss" a terminal status)
* The order of operations is very important, we need to first subscribe
and then check the last known status to prevent race conditions
* If the channel gets dropped, we return an error on purpose

jif-oai · 2026-01-12 12:16:24 +00:00

623707ab58

feat: testing harness for collab 1 (#8983 )

jif-oai · 2026-01-12 11:17:05 +00:00

86f81ca010

fix: support remote arm64 builds, as well (#9018 )

zbarsky-openai · 2026-01-10 18:41:08 -08:00

6a57d7980b

Revert "Delete announcement_tip.toml" (#9032 )

Reverts openai/codex#9003

jif-oai · 2026-01-10 07:30:14 -08:00

198289934f

Label attached images so agent can understand in-message labels (#8950 )

Agent wouldn't "see" attached images and would instead try to use the
view_file tool:
<img width="1516" height="504" alt="image"
src="https://github.com/user-attachments/assets/68a705bb-f962-4fc1-9087-e932a6859b12"
/>

In this PR, we wrap image content items in XML tags with the name of
each image (now just a numbered name like `[Image #1]`), so that the
model can understand inline image references (based on name). We also
put the image content items above the user message which the model seems
to prefer (maybe it's more used to definitions being before references).

We also tweak the view_file tool description which seemed to help a bit

Results on a simple eval set of images:

Before
<img width="980" height="310" alt="image"
src="https://github.com/user-attachments/assets/ba838651-2565-4684-a12e-81a36641bf86"
/>

After
<img width="918" height="322" alt="image"
src="https://github.com/user-attachments/assets/10a81951-7ee6-415e-a27e-e7a3fd0aee6f"
/>

```json
[
  {
    "id": "single_describe",
    "prompt": "Describe the attached image in one sentence.",
    "images": ["image_a.png"]
  },
  {
    "id": "single_color",
    "prompt": "What is the dominant color in the image? Answer with a single color word.",
    "images": ["image_b.png"]
  },
  {
    "id": "orientation_check",
    "prompt": "Is the image portrait or landscape? Answer in one sentence.",
    "images": ["image_c.png"]
  },
  {
    "id": "detail_request",
    "prompt": "Look closely at the image and call out any small details you notice.",
    "images": ["image_d.png"]
  },
  {
    "id": "two_images_compare",
    "prompt": "I attached two images. Are they the same or different? Briefly explain.",
    "images": ["image_a.png", "image_b.png"]
  },
  {
    "id": "two_images_captions",
    "prompt": "Provide a short caption for each image (Image 1, Image 2).",
    "images": ["image_c.png", "image_d.png"]
  },
  {
    "id": "multi_image_rank",
    "prompt": "Rank the attached images from most colorful to least colorful.",
    "images": ["image_a.png", "image_b.png", "image_c.png"]
  },
  {
    "id": "multi_image_choice",
    "prompt": "Which image looks more vibrant? Answer with 'Image 1' or 'Image 2'.",
    "images": ["image_b.png", "image_d.png"]
  }
]
```

charley-oai · 2026-01-09 21:33:45 -08:00

6709ad8975

fix: include AGENTS.md as repo root marker for integration tests (#9010 )

As explained in `codex-rs/core/BUILD.bazel`, including the repo's own
`AGENTS.md` is a hack to get some tests passing. We should fix this
properly, but I wanted to put stake in the ground ASAP to get `just
bazel-remote-test` working and then add a job to `bazel.yml` to ensure
it keeps working.

Michael Bolin · 2026-01-09 17:09:59 -08:00

cf515142b0

fix: add .git to .bazelignore (#9008 )

As noted in the comment, this was causing a problem for me locally
because Sapling backed up some files under `.git/sl` named `BUILD.bazel`
and so Bazel tried to parse them.

It's a bit surprising that Bazel does not ignore `.git` out of the box
such that you have to opt-in to considering it rather than opting-out.

Michael Bolin · 2026-01-10 00:55:02 +00:00

74b2238931

Add URL to responses error messages (#8984 )

Put the URL in error messages, to aid debugging Codex pointing at wrong
endpoints.

<img width="759" height="164" alt="Screenshot 2026-01-09 at 16 32 49"
src="https://github.com/user-attachments/assets/77a0622c-955d-426d-86bb-c035210a4ecc"
/>

gt-oai · 2026-01-10 00:53:47 +00:00

cc0b5e8504

Add model provider info to /status if non-default (#8981 )

Add model provider info to /status if non-default

Enterprises are running Codex and migrating between proxied / API key
auth and SIWC. If you accidentally run Codex with `OPENAI_BASE_URL=...`,
which is surprisingly easy to do, we don't tend to surface this anywhere
and it may lead to breakage. One suggestion was to include this
information in `/status`:

<img width="477" height="157" alt="Screenshot 2026-01-09 at 15 45 34"
src="https://github.com/user-attachments/assets/630ce68f-c856-4a2b-a004-7df2fbe5de93"
/>

gt-oai · 2026-01-10 00:53:34 +00:00

8e49a2c0d1

Refactor remote models tests to use TestCodex builder (#8940 )

- add `with_model_provider` to the test codex builder
- replace the bespoke remote models harness with `TestCodex` in
`remote_models` tests

Ahmed Ibrahim · 2026-01-09 15:11:56 -08:00

af1ed2685e

Delete announcement_tip.toml (#9003 )

pakrym-oai · 2026-01-09 14:47:46 -08:00

1a0e2e612b

Add hierarchical agent prompt (#8996 )

pakrym-oai · 2026-01-09 13:47:37 -08:00

acfd94f625

Log unhandled sse events (#8949 )

pakrym-oai · 2026-01-09 12:36:07 -08:00

cabf85aa18

fix: harden arg0 helper PATH handling (#8766 )

### Motivation
- Avoid placing PATH entries under the system temp directory by creating
the helper directory under `CODEX_HOME` instead of
`std::env::temp_dir()`.
- Fail fast on unsafe configuration by rejecting `CODEX_HOME` values
that live under the system temp root to prevent writable PATH entries.

### Testing
- Ran `just fmt`, which completed with a non-blocking
`imports_granularity` warning.
- Ran `just fix -p codex-arg0` (Clippy fixes) which completed
successfully.
- Ran `cargo test -p codex-arg0` and the test run completed
successfully.

viyatb-oai · 2026-01-09 12:35:54 -08:00

bc284669c2

fix(app-server): set originator header from initialize (re-revert) (#8988 )

Reapplies https://github.com/openai/codex/pull/8873 which was reverted
due to merge conflicts

Owen Lin · 2026-01-09 12:09:30 -08:00

fbe883318d

feat: add support for building with Bazel (#8875 )

This PR configures Codex CLI so it can be built with
[Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc`
includes configuration so that remote builds can be done using
[BuildBuddy](https://www.buildbuddy.io).

If you are familiar with Bazel, things should work as you expect, e.g.,
run `bazel test //... --keep-going` to run all the tests in the repo,
but we have also added some new aliases in the `justfile` for
convenience:

- `just bazel-test` to run tests locally
- `just bazel-remote-test` to run tests remotely (currently, the remote
build is for x86_64 Linux regardless of your host platform). Note we are
currently seeing the following test failures in the remote build, so we
still need to figure out what is happening here:

```
failures:
    suite::compact::manual_compact_twice_preserves_latest_user_messages
    suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
    suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view
```

- `just build-for-release` to build release binaries for all
platforms/architectures remotely

To setup remote execution:
- [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI
employees should also request org access at
https://openai.buildbuddy.io/join/ with their `@openai.com` email
address.)
- [Copy your API key](https://app.buildbuddy.io/docs/setup/) to
`~/.bazelrc` (add the line `build
--remote_header=x-buildbuddy-api-key=YOUR_KEY`)
- Use `--config=remote` in your `bazel` invocations (or add `common
--config=remote` to your `~/.bazelrc`, or use the `just` commands)

## CI

In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which
uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners
(we are working on supporting Windows, but that is not ready yet). Note
that the failures we are seeing in `just bazel-remote-test` do not occur
on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml`
is green right now.

The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so
that macOS CI jobs build _remotely_ on Linux hosts (using the
`docker://docker.io/mbolin491/codex-bazel` Docker image declared in the
root `BUILD.bazel`) using cross-compilation to build the macOS
artifacts. Then these artifacts are downloaded locally to GitHub's macOS
runner so the tests can be executed natively. This is the relevant
config that enables this:

```
common:macos --config=remote
common:macos --strategy=remote
common:macos --strategy=TestRunner=darwin-sandbox,local
```

Because of the remote caching benefits we get from BuildBuddy, these new
CI jobs can be extremely fast! For example, consider these two jobs that
ran all the tests on Linux x86_64:

- Bazel 1m37s
https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875
- Cargo 9m20s
https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875

For now, we will continue to run both the Bazel and Cargo jobs for PRs,
but once we add support for Windows and running Clippy, we should be
able to cutover to using Bazel exclusively for PRs, which should still
speed things up considerably. We will probably continue to run the Cargo
jobs post-merge for commits that land on `main` as a sanity check.

Release builds will also continue to be done by Cargo for now.

Earlier attempt at this PR: https://github.com/openai/codex/pull/8832
Earlier attempt to add support for Buck2, now abandoned:
https://github.com/openai/codex/pull/8504

---------

Co-authored-by: David Zbarsky <dzbarsky@gmail.com>
Co-authored-by: Michael Bolin <mbolin@openai.com>

zbarsky-openai · 2026-01-09 11:09:43 -08:00

2a06d64bc9

fix: add tui.alternate_screen config and --no-alt-screen CLI flag for Zellij scrollback (#8555 )

Fixes #2558

Codex uses alternate screen mode (CSI 1049) which, per xterm spec,
doesn't support scrollback. Zellij follows this strictly, so users can't
scroll back through output.

**Changes:**
- Add `tui.alternate_screen` config: `auto` (default), `always`, `never`
- Add `--no-alt-screen` CLI flag
- Auto-detect Zellij and skip alt screen (uses existing `ZELLIJ` env var
detection)

**Usage:**
```bash
# CLI flag
codex --no-alt-screen

# Or in config.toml
[tui]
alternate_screen = "never"
```

With default `auto` mode, Zellij users get working scrollback without
any config changes.

---------

Co-authored-by: Josh McKinney <joshka@openai.com>

Helmut Januschka · 2026-01-09 18:38:26 +00:00

7daaabc795

renaming: task to turn (#8963 )

jif-oai · 2026-01-09 17:31:17 +00:00

1aed01e99f

nit: rename to analytics_enabled (#8978 )

jif-oai · 2026-01-09 17:18:42 +00:00

ed64804cb5

Revert "fix(app-server): set originator header from initialize JSON-RPC request" (#8986 )

Reverts openai/codex#8873

jif-oai · 2026-01-09 17:00:53 +00:00

5c380d5b1e

chore: nuke telemetry file (#8985 )

jif-oai · 2026-01-09 08:55:21 -08:00

46b0c4acbb

Add config to disable /feedback (#8909 )

Some enterprises do not want their users to be able to `/feedback`.

<img width="395" height="325" alt="image"
src="https://github.com/user-attachments/assets/2dae9c0b-20c3-4a15-bcd3-0187857ebbd8"
/>

Adds to `config.toml`:

```toml
[feedback]
enabled = false
```

I've deliberately decided to:
1. leave other references to `/feedback` (e.g. in the interrupt message,
tips of the day) unchanged. I think we should continue to promote the
feature even if it is not usable currently.
2. leave the `/feedback` menu item selectable and display an error
saying it's disabled, rather than remove the menu item (which I believe
would raise more questions).

but happy to discuss these.

This will be followed by a change to requirements.toml that admins can
use to force the value of feedback.enabled.

gt-oai · 2026-01-09 16:33:48 +00:00

5b5a5b92b5

fix(app-server): set originator header from initialize JSON-RPC request (#8873 )

**Motivation**
The `originator` header is important for codex-backend’s Responses API
proxy because it identifies the real end client (codex cli, codex vscode
extension, codex exec, future IDEs) and is used to categorize requests
by client for our enterprise compliance API.

Today the `originator` header is set by either:
- the `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var (our VSCode extension
does this)
- calling `set_default_originator()` which sets a global immutable
singleton (`codex exec` does this)

For `codex app-server`, we want the `initialize` JSON-RPC request to set
that header because it is a natural place to do so. Example:
```json
{
  "method": "initialize",
  "id": 0,
  "params": {
    "clientInfo": {
      "name": "codex_vscode",
      "title": "Codex VS Code Extension",
      "version": "0.1.0"
    }
  }
}
```
and when app-server receives that request, it can call
`set_default_originator()`. This is a much more natural interface than
asking third party developers to set an env var.

One hiccup is that `originator()` reads the global singleton and locks
in the value, preventing a later `set_default_originator()` call from
setting it. This would be fine but is brittle, since any codepath that
calls `originator()` before app-server can process an `initialize`
JSON-RPC call would prevent app-server from setting it. This was
actually the case with OTEL initialization which runs on boot, but I
also saw this behavior in certain tests.

Instead, what we now do is:
- [unchanged] If `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var is set,
`originator()` would return that value and `set_default_originator()`
with some other value does NOT override it.
- [new] If no env var is set, `originator()` would return the default
value which is `codex_cli_rs` UNTIL `set_default_originator()` is called
once, in which case it is set to the new value and becomes immutable.
Later calls to `set_default_originator()` returns
`SetOriginatorError::AlreadyInitialized`.

**Other notes**
- I updated `codex_core::otel_init::build_provider` to accepts a service
name override, and app-server sends a hardcoded `codex_app_server`
service name to distinguish it from `codex_cli_rs` used by default (e.g.
TUI).

**Next steps**
- Update VSCE to set the proper value for `clientInfo.name` on
`initialize` and drop the `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var.
- Delete support for `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` in codex-rs.

Owen Lin · 2026-01-09 08:17:13 -08:00

ea56186c2b

Work around crash in system-configuration library (#8954 )

This is a proposed fix for #8912

Information provided by Codex:

no_proxy means “don’t use any system proxy settings for this client,”
even if macOS has proxies configured in System Settings or via
environment. On macOS, reqwest’s proxy discovery can call into the
system-configuration framework; that’s the code path that was panicking
with “Attempted to create a NULL object.” By forcing a direct connection
for the OAuth discovery request, we avoid that proxy-resolution path
entirely, so the system-configuration crate never gets invoked and the
panic disappears.

Effectively:

With proxies: reqwest asks the OS for proxy config →
system-configuration gets touched → panic.
With no_proxy: reqwest skips proxy lookup → no system-configuration call
→ no panic.
So the fix doesn’t change any MCP protocol behavior; it just prevents
the OAuth discovery probe from touching the macOS proxy APIs that are
crashing in the reported environment.

This fix changes behavior for the OAuth discovery probe used in codex
mcp list/auth status detection. With no_proxy, that probe won’t use
system or env proxy settings, so:

If a server is only reachable via a proxy, the discovery call may fail
and we’ll show auth as Unsupported/NotLoggedIn incorrectly.
If the server is reachable directly (common case), behavior is
unchanged.



As an alternative, we could try to get a fix into the
[system-configuration](https://github.com/mullvad/system-configuration-rs)
library. It looks like this library is still under development but has
slow release pace.

Eric Traut · 2026-01-09 08:11:34 -07:00

cacdae8c05

chore: update metrics temporality (#8901 )

jif-oai · 2026-01-09 14:57:42 +00:00

bc92dc5cf0

chore: metrics tool call (#8975 )

jif-oai · 2026-01-09 13:28:43 +00:00

7e5b3e069e

chore: add approval metric (#8970 )

jif-oai · 2026-01-09 13:10:31 +00:00

e2e3f4490e

chore: add mcp call metric (#8973 )

jif-oai · 2026-01-09 13:09:21 +00:00

225614d7fb

chore: move otel provider outside of trace module (#8968 )

jif-oai · 2026-01-09 12:42:54 +00:00

16c66c37eb

chore: non mutable btree when building specs (#8969 )

jif-oai · 2026-01-09 12:21:55 +00:00

e9c548c65e

nit: rename session metric (#8966 )

jif-oai · 2026-01-09 11:55:57 +00:00

fceae86581

feat: first pass on clb tool (#8930 )

jif-oai · 2026-01-09 11:54:05 +00:00

568b938c80

[device-auth] When headless environment is detected, show device login flow instead. (#8756 )

When headless environment is detected, show device login flow instead.

Matthew Zeng · 2026-01-08 21:48:30 -08:00

24d6e0114f

fix: remove existing process hardening from Codex CLI (#8951 )

As explained in https://github.com/openai/codex/issues/8945 and
https://github.com/openai/codex/issues/8472, there are legitimate cases
where users expect processes spawned by Codex to inherit environment
variables such as `LD_LIBRARY_PATH` and `DYLD_LIBRARY_PATH`, where
failing to do so can cause significant performance issues.

This PR removes the use of
`codex_process_hardening::pre_main_hardening()` in Codex CLI (which was
added not in response to a known security issue, but because it seemed
like a prudent thing to do from a security perspective:
https://github.com/openai/codex/pull/4521), but we will continue to use
it in `codex-responses-api-proxy`. At some point, we probably want to
introduce a slightly different version of
`codex_process_hardening::pre_main_hardening()` in Codex CLI that
excludes said environment variables from the Codex process itself, but
continues to propagate them to subprocesses.

Michael Bolin · 2026-01-08 21:19:34 -08:00

d3ff668f68

Add 5s timeout to models list call + integration test (#8942 )

- Enforce a 5s timeout around the remote models refresh to avoid hanging
/models calls.

Ahmed Ibrahim · 2026-01-08 18:06:10 -08:00

81caee3400

fix: treat null MCP resource args as empty (#8917 )

Handle null tool arguments in the MCP resource handler so optional
resource tools accept null without failing, preserving normal JSON
parsing for non-null payloads and improving robustness when models emit
null; this avoids spurious argument parse errors for list/read MCP
resource calls.

Thibault Sottiaux · 2026-01-08 17:47:02 -08:00

51dd5af807

Elevated sandbox NUX (#8789 )

Elevated Sandbox NUX:

* prompt for elevated sandbox setup when agent mode is selected (via
/approvals or at startup)
* prompt for degraded sandbox if elevated setup is declined or fails
* introduce /elevate-sandbox command to upgrade from degraded
experience.

iceweasel-oai · 2026-01-08 16:23:06 -08:00

6372ba9d5f

fix: increase timeout for wait_for_event() for Bazel (#8946 )

This seems to be necessary to get the Bazel builds on ARM Linux to go
green on https://github.com/openai/codex/pull/8875.

I don't feel great about timeout-whack-a-mole, but we're still learning
here...

Michael Bolin · 2026-01-08 15:37:46 -08:00

bdfdebcfa1

Attempt to reload auth as a step in 401 recovery (#8880 )

When authentication fails, first attempt to reload the auth from file
and then attempt to refresh it.

pakrym-oai · 2026-01-08 15:06:44 -08:00

62a73b6d58

[chore] move app server tests from chat completion to responses (#8939 )

We are deprecating chat completions. Move all app server tests from chat
completion to responses.

Celia Chen · 2026-01-08 22:27:55 +00:00

be4364bb80

remove get_responses_requests and get_responses_request_bodies to use in-place matcher (#8858 )

Ahmed Ibrahim · 2026-01-08 13:57:48 -08:00

0d3e673019

feat: fork conversation/thread (#8866 )

## Summary
- add thread/conversation fork endpoints to the protocol (v1 + v2)
- implement fork handling in app-server using thread manager and config
overrides
- add fork coverage in app-server tests and document `thread/fork` usage

Anton Panasenko · 2026-01-08 12:54:20 -08:00

41a317321d

[fix] app server flaky send_messages test (#8874 )

Fix flakiness of CI test:
https://github.com/openai/codex/actions/runs/20350530276/job/58473691434?pr=8282

This PR does two things:
1. move the flakiness test to use responses API instead of chat
completion API
2. make mcp_process agnostic to the order of
responses/notifications/requests that come in, by buffering messages not
read

Celia Chen · 2026-01-08 20:41:21 +00:00

051bf81df9

fix: correct login shell mismatch in the accept_elicitation_for_prompt_rule() test (#8931 )

Because the path to `git` is used to construct `elicitations_to_accept`,
we need to ensure that we resolve which `git` to use the same way our
Bash process will:


https://github.com/openai/codex/blob/c9c65606852c0cda9d983b4917359a0826a4b7f0/codex-rs/exec-server/tests/suite/accept_elicitation.rs#L59-L69

This fixes an issue when running the test on macOS using Bazel
(https://github.com/openai/codex/pull/8875) where the login shell chose
`/opt/homebrew/bin/git` whereas the non-login shell chose
`/usr/bin/git`.

Michael Bolin · 2026-01-08 12:37:38 -08:00

a70f5b0b3c

fix: increase timeout for tests that have been flaking with timeout issues (#8932 )

I have seen this test flake out sometimes when running the macOS build
using Bazel in CI: https://github.com/openai/codex/pull/8875. Perhaps
Bazel runs with greater parallelism, inducing a heavier load, causing an
issue?

Michael Bolin · 2026-01-08 20:31:03 +00:00

224c4867dd

nit: parse_arguments (#8927 )

jif-oai · 2026-01-08 19:49:17 +00:00

c9c6560685

Immutable CodexAuth (#8857 )

Historically we started with a CodexAuth that knew how to refresh it's
own tokens and then added AuthManager that did a different kind of
refresh (re-reading from disk).

I don't think it makes sense for both `CodexAuth` and `AuthManager` to
be mutable and contain behaviors.

Move all refresh logic into `AuthManager` and keep `CodexAuth` as a data
object.

pakrym-oai · 2026-01-08 11:43:56 -08:00

634764ece9

add tooltip hint for shell commands (!) (#8926 )

I didn't know this existed because its not listed in the hints.

Felipe Petroski Such · 2026-01-08 19:31:20 +00:00

5bc3e325a6

3718 Commits