Files
codex/codex-rs/core
T
Curtis 'Fjord' Hawthorne 0d76d029b7 Fix js_repl in-flight tool-call waiter race (#11800)
## Summary

This PR fixes a race in `js_repl` tool-call draining that could leave an
exec waiting indefinitely for in-flight tool calls to finish.

The fix is in:

-
`/Users/fjord/code/codex-jsrepl-seq/codex-rs/core/src/tools/js_repl/mod.rs`

## Problem

`js_repl` tracks in-flight tool calls per exec and waits for them to
drain on completion/timeout/cancel paths.
The previous wait logic used a check-then-wait pattern with `Notify`
that could miss a wakeup:

1. Observe `in_flight > 0`
2. Drop lock
3. Register wait (`notified().await`)

If `notify_waiters()` happened between (2) and (3), the waiter could
sleep until another notification that never comes.

## What changed

- Updated all exec-tool-call wait loops to create an owned notification
future while holding the lock:
- use `Arc<Notify>::notified_owned()` instead of cloning notify and
awaiting later.
- Applied this consistently to:
  - `wait_for_exec_tool_calls`
  - `wait_for_all_exec_tool_calls`
  - `wait_for_exec_tool_calls_map`

This preserves existing behavior while eliminating the lost-wakeup
window.

## Test coverage

Added a regression test:

- `wait_for_exec_tool_calls_map_drains_inflight_calls_without_hanging`

The test repeatedly races waiter/finisher tasks and asserts bounded
completion to catch hangs.

## Impact

- No API changes.
- No user-facing behavior changes intended.
- Improves reliability of exec lifecycle boundaries when tool calls are
still in flight.


#### [git stack](https://github.com/magus/git-stack-cli)
-  `1` https://github.com/openai/codex/pull/11796
- 👉 `2` https://github.com/openai/codex/pull/11800
-  `3` https://github.com/openai/codex/pull/10673
-  `4` https://github.com/openai/codex/pull/10670
0d76d029b7 · 2026-02-14 01:24:52 +00:00
History
..
2026-02-10 17:25:35 -08:00

codex-core

This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.

Dependencies

Note that codex-core makes some assumptions about certain helper utilities being available in the environment. Currently, this support matrix is:

macOS

Expects /usr/bin/sandbox-exec to be present.

When using the workspace-write sandbox policy, the Seatbelt profile allows writes under the configured writable roots while keeping .git (directory or pointer file), the resolved gitdir: target, and .codex read-only.

Network access and filesystem read/write roots are controlled by SandboxPolicy. Seatbelt consumes the resolved policy and enforces it.

Seatbelt also supports macOS permission-profile extensions layered on top of SandboxPolicy:

  • no extension profile provided: keeps legacy default preferences read access (user-preference-read).
  • extension profile provided with no macos_preferences grant: does not add preferences access clauses.
  • macos_preferences = "readonly": enables cfprefs read clauses and user-preference-read.
  • macos_preferences = "readwrite": includes readonly clauses plus user-preference-write and cfprefs shm write clauses.
  • macos_automation = true: enables broad Apple Events send permissions.
  • macos_automation = ["com.apple.Notes", ...]: enables Apple Events send only to listed bundle IDs.
  • macos_accessibility = true: enables com.apple.axserver mach lookup.
  • macos_calendar = true: enables com.apple.CalendarAgent mach lookup.

Linux

Expects the binary containing codex-core to run the equivalent of codex sandbox linux (legacy alias: codex debug landlock) when arg0 is codex-linux-sandbox. See the codex-arg0 crate for details.

All Platforms

Expects the binary containing codex-core to simulate the virtual apply_patch CLI when arg1 is --codex-run-as-apply-patch. See the codex-arg0 crate for details.