Codex CLI is Going Native

[fouad-openai]

Hello! Thank you all for the excitement, feedback, and contributions over the past month or so since launch. It's been incredible to hear from all of you building with Codex CLI and now Codex Web¹

Special thank you to all the contributors who opened PRs to improve the CLI for everyone. From fixing bugs to adding features, it's been a lot of fun co-developing this with all of you. We wanted to share an update on a few recurring themes: cross-platform stability, security, performance, and extensibility.

We're continuing to address feedback and fix issues that we hear from the community, while we've been working on a rewrite of Codex CLI into Rust. You can try it today by running:

npm i -g @openai/codex@native
codex

If you're a TypeScript developer like me, you're probably wondering why would we do this. High-level: we want to use the best tool for the job. While Codex CLI ships with a neat terminal UI, which has been easy to whip up and iterate with React-based ink ² - the core of this project is an "agentic" harness, aka calling the model in a loop.

Our goal is to make the software pieces as efficient as possible and there were a few areas we wanted to improve:

• Zero-dependency Install — currently Node v22+ is required, which is frustrating or a blocker for some users
• Native Security Bindings — surprise! we already ship a Rust for linux sandboxing since the bindings were available
• Optimized Performance — no runtime garbage collection, resulting in lower memory consumption
• Extensible Protocol — we've been working on a "wire protocol" for Codex CLI to allow developers to extend the agent in different languages (including Type/JavaScript, Python, etc) and MCPs (already supported in Rust)

We're planning to continue merging bugfixes in the TypeScript implementation, while we get the Rust implementation to experience and feature parity in the coming weeks. We'll share more updates soon on how TypeScript and other languages like Python will fit in long-term into this project.

If working in Rust, contributing to codex-cli, and building new modes of agentic coding is exciting to you - we're growing our team! Please reach out to us at: [email protected]

We're excited to hear your feedback on the new version of Codex CLI as we work towards making it the default experience in the coming weeks. Happy building!

Footnotes

1. https://openai.com/index/introducing-codex/ ↩

2. https://github.com/vadimdemedes/ink ↩

[jasonkneen]

arg, it's telling me I have to be verified as an org but there's a bug in your backend -- I'm a pro account holder but I can't verify my org as the 3rd party verification system won't let me generate a new token etc. help!

[troykelly]

@jasonkneen the third-party verification system just plain ol' doesn't work™. I had to keep harassing support and the third-party vendor for support until OpenAI just switched us to verified - it will take a few weeks, given how bad both their support is - but it's the only solution I've come across.

[bpostlethwaite]

@fouad-openai thanks for the write up! Could you expand a bit more upon

Native Security Bindings — surprise! we already ship a Rust for linux sandboxing since the bindings were available

I'm interested in learning more about how Codex is handling Sandboxing. Thanks!

[bolinfest]

@bpostlethwaite we should write things up in more detail (and refactor some of the code so it's easier to follow), but the high level is that we have a set of sandbox permissions:

codex/codex-rs/core/src/protocol.rs

Lines 250 to 282 in 7896b10

	/// Permissions that should be granted to the sandbox in which the agent
	/// operates.
	#[derive(Debug, Clone, PartialEq, Eq, Hash, Serialize, Deserialize)]
	#[serde(rename_all = "kebab-case")]
	pub enum SandboxPermission {
	/// Is allowed to read all files on disk.
	DiskFullReadAccess,
	/// Is allowed to write to the operating system's temp dir that
	/// is restricted to the user the agent is running as. For
	/// example, on macOS, this is generally something under
	/// `/var/folders` as opposed to `/tmp`.
	DiskWritePlatformUserTempFolder,
	/// Is allowed to write to the operating system's shared temp
	/// dir. On UNIX, this is generally `/tmp`.
	DiskWritePlatformGlobalTempFolder,
	/// Is allowed to write to the current working directory (in practice, this
	/// is the `cwd` where `codex` was spawned).
	DiskWriteCwd,
	/// Is allowed to the specified folder. `PathBuf` must be an
	/// absolute path, though it is up to the caller to canonicalize
	/// it if the path contains symlinks.
	DiskWriteFolder { folder: PathBuf },
	/// Is allowed to write to any file on disk.
	DiskFullWriteAccess,
	/// Can make arbitrary network requests.
	NetworkFullAccess,
	}

that can be aggregated to define a SandboxPolicy. We map the SandboxPolicy to an appropriate set of CLI args to a helper binary that spawns a subprocess in the sandbox:

• On macOS, we use /usr/bin/sandbox-exec:

  codex/codex-rs/core/src/exec.rs

  Lines 270 to 327 in 7896b10

  	fn create_seatbelt_command_args(
  	command: Vec<String>,
  	sandbox_policy: &SandboxPolicy,
  	cwd: &Path,
  	) -> Vec<String> {
  	let (file_write_policy, extra_cli_args) = {
  	if sandbox_policy.has_full_disk_write_access() {
  	// Allegedly, this is more permissive than `(allow file-write*)`.
  	(
  	r#"(allow file-write* (regex #"^/"))"#.to_string(),
  	Vec::<String>::new(),
  	)
  	} else {
  	let writable_roots = sandbox_policy.get_writable_roots_with_cwd(cwd);
  	let (writable_folder_policies, cli_args): (Vec<String>, Vec<String>) = writable_roots
  	.iter()
  	.enumerate()
  	.map(|(index, root)| {
  	let param_name = format!("WRITABLE_ROOT_{index}");
  	let policy: String = format!("(subpath (param \"{param_name}\"))");
  	let cli_arg = format!("-D{param_name}={}", root.to_string_lossy());
  	(policy, cli_arg)
  	})
  	.unzip();
  	if writable_folder_policies.is_empty() {
  	("".to_string(), Vec::<String>::new())
  	} else {
  	let file_write_policy = format!(
  	"(allow file-write*\n{}\n)",
  	writable_folder_policies.join(" ")
  	);
  	(file_write_policy, cli_args)
  	}
  	}
  	};
  	let file_read_policy = if sandbox_policy.has_full_disk_read_access() {
  	"; allow read-only file operations\n(allow file-read*)"
  	} else {
  	""
  	};
  	// TODO(mbolin): apply_patch calls must also honor the SandboxPolicy.
  	let network_policy = if sandbox_policy.has_full_network_access() {
  	"(allow network-outbound)\n(allow network-inbound)\n(allow system-socket)"
  	} else {
  	""
  	};
  	let full_policy = format!(
  	"{MACOS_SEATBELT_BASE_POLICY}\n{file_read_policy}\n{file_write_policy}\n{network_policy}"
  	);
  	let mut seatbelt_args: Vec<String> = vec!["-p".to_string(), full_policy];
  	seatbelt_args.extend(extra_cli_args);
  	seatbelt_args.push("--".to_string());
  	seatbelt_args.extend(command);
  	seatbelt_args
  	}

• On Linux, we build our own CLI that uses Landlock/seccomp: https://github.com/openai/codex/blob/main/codex-rs/linux-sandbox/README.md

In both cases, the policy is applied to the process spawned (and to any processes it spawns), so it applies to an entire process tree.

[bpostlethwaite]

Thanks, appreciated!

[cweagans]

@bolinfest man sandbox-exec on macOS says that's deprecated:

NAME
     sandbox-exec – execute within a sandbox (DEPRECATED)

[...]

DESCRIPTION
     The sandbox-exec command is DEPRECATED.  Developers who wish to sandbox an app should instead adopt the App
     Sandbox feature described in the App Sandbox Design Guide.  The sandbox-exec command enters a sandbox using a
     profile specified by the -f, -n, or -p option and executes command with arguments.

Do you have other mechanisms in mind for whenever Apple decides to remove sandbox-exec?

[bolinfest]

@cweagans I am aware of the deprecation warning, but we'll cross that bridge when we come to it.

[prassanna-ravishankar]

This is real good news. Hoping to see the wire protocol when it comes out

[bolinfest]

Currently, the de facto wire protocol is what is defined in https://github.com/openai/codex/blob/main/codex-rs/core/src/protocol.rs, though it is not "stable" today. As noted on https://github.com/openai/codex/blob/main/codex-rs/README.md, we also provide Codex as an MCP server. The API for the tool call to invoke Codex within the MCP server is admittedly also unstable, but we may just go with that rather than a separate CLI for speaking the wire protocol since the two are already so similar (bidirectional streams of newline-delimited-JSON payloads).

[oxplot]

Great! Since going native, would be great to have this as a package in brew/apt/... as well.

[olgeni]

I typed "Hello" and was told that "Your organization must be verified to generate reasoning summaries".

Surely there is a mighty good reason, but the first impact might be less than stellar 😅

[Kolger]

@bolinfest Now it works with the latest version available in Releases with model_reasoning_effort = "none" setting in ~/.codex/config.toml, thanks!

[bolinfest]

@Kolger good to hear! Though which model were you using? I believe #1199 should have also fixed things such that it "does the right thing by default" for OpenAI models such that you shouldn't have to set model_reasoning_effort explicitly.

[Kolger]

@bolinfest I tried o4-mini and codex-mini-latest - both didn't work. They still don't work on the latest version with default settings, only with the model_reasoning_effort = "none" setting

[bolinfest]

@Kolger thanks for investigating. That seems good given that #1199 links to the analogous code in the TypeScript CLI, which indeed uses if (this.model.startsWith("o") || this.model.startsWith("codex")) to determine whether to enable reasoning.

@fouad-openai are you familiar with this?

@Kolger I do not see this when I use the CLI with my work account, but I do get it on my personal account. Indeed, the error message says:

Your organization must be verified to generate reasoning summaries. Please go to: https://platform.openai.com/settings/organization/general and click on Verify Organization.

When I go there, I get Payment method required and am forced to add a payment method.

So my questions are:

1. Is that the same error message you were getting and is that the flow you were kicked into?
2. Did you also have that issue with the TypeScript CLI and did you disable reasoning, or were you somehow getting reasoning in the TypeScript CLI without verifying your organization? (Or maybe those errors were happening in the TypeScript CLI and were ignored or reasoning was disabled behind the scenes if you hit them?)

[Kolger]

@bolinfest

1. It is the same error. I added a payment method a long time ago and everything is going well with the payment. But it forces me to send my ID. I can do that, I just was confused by the question - why does the Codex TypeScript CLI work well, but the Codex Rust CLI doesn't work?
2. I've been using Codex TypeScript CLI since it was released with the o4-mini model. It still works. I didn't change any settings in Codex TypeScript CLI. It just works. When I decided to try Codex Rust CLI, I was unable to use it because of this "Your organization must be verified to generate reasoning summaries" error.
   

[jasonkneen]

exactly, and since the whole verification is broken for me despite having a pro account it means I can't use the published version at all (rust)

[bolinfest]

@jasonkneen To clarify, with your Pro account, was the login flow in the TypeScript CLI working for you, but not Rust (because it was non-existent?). I have since added codex login to the Rust CLI:

• feat: add support for login with ChatGPT #1212
• feat: port maybeRedeemCredits() from get-api-key.tsx to login_with_chatgpt.py #1221

And the latest GitHub release has binaries with these fixes:

https://github.com/openai/codex/releases/tag/codex-rs-5fc3c3023d9f179fb416b2722d1434bac278e916-1-rust-v0.0.2506060849

Could you give it a try and let me know if things work for you now?

[bolinfest]

@jasonkneen Today I filed #1243 to try to keep all the discussion around login problems in one place, so please feel free to add to that issue!

[Rafler]

Hey guys. Not sure it's the right place to post, but tried to configure mcp servers for codex-rs based on https://github.com/openai/codex/blob/main/codex-rs/config.md

And when calling some tools I get error about naming length, despite any of the name i use for servers are not that long

ERROR: unexpected status 400 Bad Request: { "error": { "message": "Invalid 'tools[5].name': string too long. Expected a string with maximum length 64, but got a string with length 72 instead.", "type": "invalid_request_error", "param": "tools[5].name", "code": "string_above_max_length" }}

[bolinfest]

@Rafler If you set the RUST_LOG environment variable to something like RUST_LOG=debug and then tail -F ~/.codex/log/codex-tui.log, you should be able to see a lot of info at runtime and maybe that will help?

[bolinfest]

Though for debugging MCPs in general, I use https://github.com/modelcontextprotocol/inspector. That should make it easy to see the full list of tools provided by your MCP.

[bolinfest]

Also, which model is returning the error message about tool name length?

[Rafler]

@bolinfest codex-mini

[bolinfest]

@Rafler I filed #1289 so I don't lose track of this.

[nilslice]

Thanks for opening up this discussion - really excited about what's coming.

With regard to:

Extensible Protocol — we've been working on a "wire protocol" for Codex CLI to allow developers to extend the agent in different languages (including Type/JavaScript, Python, etc) and MCPs (already supported in Rust)

I would like to propose supporting WebAssembly isolation, similar to how it looks like you already support linux sandboxes. More specifically, for the use of embedded plugins. This way any user (or Codex itself), could write a plugin in practically any language, compile it to a WebAssembly module, and then securely run it in the same Codex process. This would work anywhere Codex works, and not need to negotiate over a remote protocol.

WebAssembly is OS-agnostic, so any extension written would work in any system across clouds, desktops, etc (even browsers...)

There is already some prior art here in using WebAssembly for extensibility in AI systems, with mcp.run, which under the hood is mostly implemented atop Extism. With great Rust support to embed Extism into the CLI, it would be very straightforward to open up plugins to end-users who can "bring their own language" just like they could with a remote protocol.

Would the Codex team be open to further discussions here or even a POC to see how it would work?

[bolinfest]

@nilslice thanks for raising this: I'm certainly intrigued by this approach. Another option is to define a plugin more like an LSP/MCP server (where the plugin definition is the process to spawn and then communication is done via JSONL over stdin/stdout). Off the top of my head, tradeoffs are:

Separate process

• Pro: can write in really any language
• Pro (or Con, depending on your perspective...): not limited to WASM sandbox
• Con: requires Codex to do process management

WASM

• Pro: can write in any language that can target WASM (so this excludes JavaScript/TypeScript, but includes AssemblyScript?)
• Pro: can be loaded directly by Codex and does not require spawning a new process (correct?)

I'm sure there are things I'm overlooking, so please set me straight!

[nilslice]

[..] define a plugin more like an LSP/MCP server

Yea, I think it is a great approach. We did this for mcp.run, the MCP definition is in this schema, which generates bindings using an OpenAPI-like format as input. Here's a Gist for the Tools portion of the spec.

These plugins (as MCP servers) run locally as Wasm (in or out of process), or anywhere else remotely using the same code in a different process (network, cloud, edge, etc).

My opinion: The primary trade-off

Personally, the trade-off I see Wasm suffer from the most is existing code compatibility. A lot of code just (often understandably) ignores portability, and requires OS-specific libraries. These do not generally compile to Wasm without effort to fix code. When there is a developer expectation that all existing programs or libraries compile, generally its not a fit.

Aside from this, I would agree with your trade-off list. And to clarify, Wasm does support JS/TS, as well as all of these languages listed here (at least that I can vouch for), plus some others too with varying degrees of support.

[bolinfest]

I know that a number of JavaScript engines (and the browser, of course) support running WASM that bridges with JavaScript, but how do you take JavaScript and transpile it to WASM? Or does that require a JavaScript interpreter written in WASM?

[nilslice]

[..] Or does that require a JavaScript interpreter written in WASM?

Yes, exactly. In most cases (if not all that exist in any production system - e.g. Shopify Functions, mcp.run, etc), a JS runtime & interpreter is compiled to wasm and it executes the JS code, or partially evaluated JS or runtime optimized bytecode within the interpreter.

More often than not, quickjs, or a version of it is used as it's generally the most compliant implementation and compiles to a small artifact, not bloating a wasm module if it has to include its own copy of the interpreter.

[rizwankce]

Tried out the codex native and its butter smooth so far. There are some gaps between typescript version and native. Like config file support and --free or login with open AI account. But looking forward to the coming updates.

[rizwankce]

@bolinfest That was quick! I would be happy to help testing it out. Let me test and get back to you!

[rizwankce]

@bolinfest There was no git tag after #1212 so I went ahead and cloned the repo and build from source to try out.

I was able to successfully finish the full login flow. auth.json also present at codex folder with all details. Used codex to explain the login part and codex-mini was able to explain the same thing as in PR body.

[rizwankce]

I have asked codex to review codex-rs login flow PR and there were some comments which you can find here

[rizwankce]

Now that I used codex-rs for sometime, I do miss some other features. Listing out down here

• ability to hit esc or some key to quit the session when it says "working"
• ability to see and attach to history sessions
• ability to copy the suggestions some how (I tried to copy the codex suggestion but both mouse mode or normal mode I couldn't copy. so decided to ask the codex to write it in a md file)
• change the model after a chat is initiated
• change the sandbox policy after a chat is intiiated

[bolinfest]

@rizwankce Thanks for this list. I believe much of this is represented on #1262 now.

[bolinfest]

For more context on what is involved in the migration to the Rust version, I just published a "burndown" list! See #1266 for details.

[kachurun]

If anybody's interested, guys, I made a JS SDK over the Rust version of Codex to use this amazing tool directly from Node.js:
https://dev.to/kachurun/openai-codex-as-a-native-agent-in-your-typescript-nodejs-app-kii

[tomtyiu]

I was getting sandbox mandate errors.
I got Codex --auto-full to work properly, at least in Window 10 Enterprise's VScode or powershell program
Type:
$env:CODEX_UNSAFE_ALLOW_NO_SANDBOX=1
npx codex "your prompt here"
or
Command prompt:
set CODEX_UNSAFE_ALLOW_NO_SANDBOX=1
npx codex "your prompt here"

I have VSCode extension for Codex CLI.
https://marketplace.visualstudio.com/items?itemName=ThomasYiu0447.andromeda-codex

[nmurrell07]

I was excited to see that Codex can now process images, or is described as able to do so. Unfortunately this is not the case. It's getting closer though!

[yaroslavyaroslav]

Thanks a ton for all your work, guys! Thanks to this, I’ve built a first-class Sublime Text integration plugin for Codex¹. Leveraging all of Codex’s capabilities, it now stands on par with Zed or Cursor in terms of AI-assisted features. Like literally all of them:

• Bash command invocation on the local machine
• Fine-grained sandboxing of command invocations
• MCP support
• Code editing

And it just works.

Footnotes

1. https://github.com/yaroslavyaroslav/CodexSublime ↩