Code mode on v8 by cconger · Pull Request #15276 · openai/codex

cconger · 2026-03-20T05:26:29Z

Moves Code Mode to a new crate with no dependencies on codex. This create encodes the code mode semantics that we want for lifetime, mounting, tool calling.

The model-facing surface is mostly unchanged. exec still runs raw JavaScript, wait still resumes or terminates a cell_id, nested tools are still available through tools.*, and helpers like text, image, store, load, notify, yield_control, and exit still exist.

The major change is underneath that surface:

Old code mode was an external Node runtime.
New code mode is an in-process V8 runtime embedded directly in Rust.
Old code mode managed cells inside a long-lived Node runner process.
New code mode manages cells in Rust, with one V8 runtime thread per active exec.
Old code mode used JSON protocol messages over child stdin/stdout plus Node worker-thread messages.
New code mode uses Rust channels and direct V8 callbacks/events.

This PR also fixes the two migration regressions that fell out of that substrate change:

wait { terminate: true } now waits for the V8 runtime to actually stop before reporting termination.
synchronous top-level exit() now succeeds again instead of surfacing as a script error.

core/src/tools/code_mode/* is now mostly an adapter layer for the public exec / wait tools.
code-mode/src/service.rs owns cell sessions and async control flow in Rust.
code-mode/src/runtime/*.rs owns the embedded V8 isolate and JavaScript execution.
each exec spawns a dedicated runtime thread plus a Rust session-control task.
helper globals are installed directly into the V8 context instead of being injected through a source prelude.
helper modules like tools.js and @openai/code_mode are synthesized through V8 module resolution callbacks in Rust.

Also added a benchmark for showing the speed of init and use of a code mode env:

$ cargo bench -p codex-code-mode --bench exec_overhead -- --samples 30 --warm-iterations 25 --tool-counts 0,32,128
Finished [`bench` profile [optimized]](https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles) target(s) in 0.18s
     Running benches/exec_overhead.rs (target/release/deps/exec_overhead-008c440d800545ae)
exec_overhead: samples=30, warm_iterations=25, tool_counts=[0, 32, 128]
scenario       tools samples    warmups      iters      mean/exec       p95/exec       rssΔ p50       rssΔ max
cold_exec          0      30          0          1         1.13ms         1.20ms        8.05MiB        8.06MiB
warm_exec          0      30          1         25       473.43us       512.49us      912.00KiB        1.33MiB
cold_exec         32      30          0          1         1.03ms         1.15ms        8.08MiB        8.11MiB
warm_exec         32      30          1         25       509.73us       545.76us      960.00KiB        1.30MiB
cold_exec        128      30          0          1         1.14ms         1.19ms        8.30MiB        8.34MiB
warm_exec        128      30          1         25       575.08us       591.03us      736.00KiB      864.00KiB
memory uses a fresh-process max RSS delta for each scenario

Co-authored-by: Codex <noreply@openai.com>

codex-rs/code-mode/src/description.rs

codex-rs/core/src/tools/code_mode_description.rs

codex-rs/code-mode/benches/exec_overhead.rs

codex-rs/core/src/tools/js_repl/mod_tests.rs

codex-rs/code-mode/src/runtime/value.rs

codex-rs/code-mode/src/runtime/module_loader.rs

pakrym-oai · 2026-03-20T23:26:32Z

codex-rs/code-mode/src/runtime/module_loader.rs

+        && exception.to_rust_string_lossy(scope) == EXIT_SENTINEL
+}
+
+pub(super) fn resolve_tool_response(


nit: this method almost doesn't fit in this file.

pakrym-oai · 2026-03-20T23:32:57Z

codex-rs/code-mode/src/runtime/mod.rs

+}
+
+#[derive(Debug, PartialEq)]
+pub enum RuntimeResponse {


ToolResponse maybe?

codex-rs/code-mode/src/runtime/mod.rs

pakrym-oai · 2026-03-20T23:35:00Z

codex-rs/code-mode/src/runtime/mod.rs

+        call_id: String,
+        text: String,
+    },
+    Result {


There is some overlap between this and RuntimeResponse. Both have stored valis and notify.

RuntimeEvent is js => code_mode
RuntimeResponse is code_mode => Core

I think there's a lot of overlap but I think we likely shouldn't coalesce these types.

codex-rs/code-mode/src/runtime/mod.rs

pakrym-oai · 2026-03-20T23:39:09Z

codex-rs/code-mode/src/runtime/mod.rs

+            let _ = event_tx.send(RuntimeEvent::Result {
+                stored_values,
+                error_text: Some(error_text),
+            });


can we extract the send error boilderplate?

Maybe have normal rust error handling in inner method and outer method that has a single place to report errors.

I like this idea, I'd like to think on it some more and maybe follow up.

pakrym-oai · 2026-03-20T23:40:49Z

codex-rs/code-mode/src/runtime/mod.rs

+        }
+    };
+
+    match module_loader::completion_state(scope, pending_promise.as_ref()) {


do we need the pre-check or can we let the loop run and hit completion case naturally?

Hmm, I think we need this in the cases where the script finished right away, since the loop is blocked on the command_rx.recv().

codex-rs/code-mode/src/runtime/globals.rs

pakrym-oai · 2026-03-20T23:45:39Z

codex-rs/code-mode/src/runtime/callbacks.rs

+
+    let resolver = v8::Global::new(scope, resolver);
+    let Some(state) = scope.get_slot_mut::<RuntimeState>() else {
+        throw_type_error(scope, "runtime state unavailable");


same nit about native rust error handling that turns into throw_type_error in one location. Maybe .map_err(throw_type_error) in the caller

codex-rs/code-mode/src/runtime/callbacks.rs

pakrym-oai · 2026-03-20T23:52:25Z

codex-rs/code-mode/src/runtime/callbacks.rs

+    } else {
+        args.get(0)
+    };
+    let text = match serialize_output_text(scope, value) {


Good question, do we serialize the argument here? Or do we expect text? Might make sense to align with text method as you did here.

codex-rs/core/src/tools/code_mode/mod.rs

pakrym-oai · 2026-03-21T00:02:35Z

codex-rs/code-mode/src/service.rs

+    }
+
+    pub async fn replace_stored_values(&self, values: HashMap<String, JsonValue>) {
+        *self.inner.stored_values.lock().await = values;


nit for later. this should probably be merge.

pakrym-oai · 2026-03-21T00:04:26Z

codex-rs/code-mode/src/service.rs

+
+impl Drop for CodeModeTurnWorker {
+    fn drop(&mut self) {
+        if let Some(shutdown_tx) = self.shutdown_tx.take() {


do we want to join the task? or abort the task?

bit worrysome to let it hang

Yeah agreed. I think I probably need to have stricter lifecycle management for the Worker and channel. I need to think on it some.

pakrym-oai · 2026-03-21T00:07:04Z

codex-rs/code-mode/src/service.rs

+        tokio::select! {
+            maybe_event = async {
+                if runtime_closed {
+                    std::future::pending::<Option<RuntimeEvent>>().await


if runtime is closed what are we waiting for?

If the runtime queue gets closed its possible that there was already a Result to be processed in our event_rx or if one was pending. We keep listening until the v8 thread resolves which it should quickly after we hit a terminate_execution on the handle.

codex-rs/code-mode/src/service.rs

cconger force-pushed the cconger/code-mode-to-v8-on-v8-bazel-use branch 2 times, most recently from a0b714e to e4ea088 Compare March 20, 2026 21:21

cconger mentioned this pull request Mar 20, 2026

Code Mode to V8 #15247

Closed

cconger requested a review from pakrym-oai March 20, 2026 21:32

cconger and others added 3 commits March 20, 2026 21:54

Code Mode => New Crate + v8

cbd5ca8

Co-authored-by: Codex <noreply@openai.com>

Missing BUILD.bazel

94d5621

Allow Temporal in global scope

5cbeb96

cconger force-pushed the cconger/code-mode-to-v8-on-v8-bazel-use branch from e4ea088 to 5cbeb96 Compare March 20, 2026 21:55