jif 3766941161 Run Codex async main on a sized stack (#25847) ...

## Why

`Runtime::block_on` executes the top-level future on the caller's OS
thread, not on one of Tokio's worker threads. That matters for the
interactive CLI because the Tokio runtime already configures larger
worker stacks, while the process main thread can still have a smaller
platform default stack.

This showed up as a `/clear` crash on macOS: starting a fresh TUI thread
reloads config, and the stack-heavy TOML deserialization path can
overflow before the new session is actually started.

## What Changed

- Run the regular `arg0_dispatch_or_else` async entrypoint on a named
`codex-main` thread.
- Give that thread the same `TOKIO_WORKER_STACK_SIZE_BYTES` stack budget
already used for Tokio worker threads.
- Keep `Arg0DispatchPaths` and the arg0 alias guard lifetime behavior
the same.
- Resume panics from the spawned main thread so panic behavior is
preserved.

## Verification

- `cargo check -p codex-cli` currently fails because the top-level
CLI/TUI future is not `Send` under the new thread boundary.

3766941161 · 2026-06-02 16:34:48 +02:00

History

..

src

Run Codex async main on a sized stack (#25847)

2026-06-02 16:34:48 +02:00

BUILD.bazel

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

2026-01-09 11:09:43 -08:00

Cargo.toml

Disable empty Cargo test targets (#21584)

2026-05-07 15:44:17 -07:00