Windows: codex-tui app test stack overflows on clean HEAD

Open 💬 2 comments Opened Apr 25, 2026 by BaseInfinity

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows, codex-tui can abort with STATUS_STACK_OVERFLOW when running the app::tests::attach_live_thread_for_selection_rejects_unmaterialized_fallback_threads test. This reproduces from a clean detached worktree at upstream HEAD, so it is not caused by unrelated local TUI skill-popup changes.

Environment

OS: Windows
Repo: openai/codex
Clean HEAD tested: 6de6eaa0c ([4/4] Honor Streamable HTTP MCP placement (#18584))
Test path used: short path under C:\Users\stefa\codex-clean-head-proof-* to avoid Windows path-length failures from deeper worktree paths

Reproduction

From a clean detached worktree at HEAD:

cd C:\Users\stefa\codex-clean-head-proof-8868\codex-rs
cargo test -p codex-tui app::tests::attach_live_thread_for_selection_rejects_unmaterialized_fallback_threads -- --test-threads=1

Actual Result

running 1 test
test app::tests::attach_live_thread_for_selection_rejects_unmaterialized_fallback_threads ...

thread 'app::tests::attach_live_thread_for_selection_rejects_unmaterialized_fallback_threads' has overflowed its stack
error: test failed, to rerun pass `-p codex-tui --lib`

Caused by:
  process didn't exit successfully: ... (exit code: 0xc00000fd, STATUS_STACK_OVERFLOW)

A full local run of cargo test -p codex-tui also aborts with the same class of stack overflow before the suite can complete.

Expected Result

The test should pass or fail with a normal assertion. It should not abort the process with a stack overflow.

Notes

This was separated from a focused TUI skill mention popup change because the failure reproduces on clean HEAD. Keeping this as its own issue should make the root cause easier to triage without mixing it into unrelated UI behavior changes.

View original on GitHub ↗

2 Comments

etraut-openai contributor · 4 months ago

We're not seeing this in our Windows CI test runs, but I can take a look and see if there's a simple fix.

BaseInfinity · 4 months ago

Follow-up from local Windows testing after the related PR was closed:

cargo test -p codex-tui on the same checkout still aborts with STATUS_STACK_OVERFLOW in unrelated debug-heavy app::tests::* cases.
Setting RUST_MIN_STACK=16777216 before running cargo test -p codex-tui gets past the stack-overflow abort locally.
With that stack setting, the suite progresses to normal assertion failures in unrelated Windows path-display expectations:
status::helpers::tests::compose_agents_summary_includes_global_agents_path
status::helpers::tests::compose_agents_summary_names_global_agents_override
status::helpers::tests::compose_agents_summary_orders_global_before_project_agents

So from this machine, the stack-overflow part still looks real and broader than one attach-fallback test, but separable from the path-display assertion failures. I am keeping those as separate issues rather than mixing fixes.