'codex-utils-pty' assumes winapi "std" feature

Open 💬 4 comments Opened May 21, 2026 by ldlda

codex-utils-pty appears to implicitly rely on winapi/std.

Without the std feature, winapi defines c_void as an opaque empty struct instead of aliasing std::ffi::c_void.

Relevant chain:

winapi::um::winnt::HANDLE
// internally uses winapi's c_void

pub type HPCON = HANDLE;

PseudoCon::raw_handle() -> HPCON

But RawConPty::pseudoconsole_handle() returns std's RawHandle, which is based on std::ffi::c_void.

When winapi/std is enabled, both resolve compatibly, so this passes. But when building without that feature, the types diverge and compilation fails.

I suspect this works in the main workspace because the lockfile/dependency graph already enables winapi/std, but downstream standalone builds can fail.

View original on GitHub ↗

4 Comments

ldlda · 3 months ago

please let me build

ldlda · 3 months ago

ts thing is NOT a lib bro you cant just [dependency] codex-anything unless you fail builds 67 times and look at the lock file

ldlda · 3 months ago

i suspect there are more of these implicit use, i mean with codex building most of ts why wouldnt i

Herrtian · 3 months ago

I looked into this on Windows and prepared a focused branch here:

https://github.com/Herrtian/codex/tree/fix/pty-winapi-std-feature

The change is intentionally small: it adds the std feature to the winapi dependency used by codex-rs/utils/pty. That lets the winapi handle types line up with the std-backed Windows raw handle type exposed by RawConPty::pseudoconsole_handle().

Validation I ran:

git diff --check -- codex-rs/utils/pty/Cargo.toml
cargo check -p codex-utils-pty

PR creation appears to be limited by the repo's invitation-only contribution policy, so I'm leaving the branch here instead of opening an unsolicited PR. If this matches the intended fix, could a maintainer invite a PR or pick up the branch internally?