core-agent-ide/codex-rs/process-hardening/Cargo.toml

[package]
name = "codex-process-hardening"
version.workspace = true
edition.workspace = true
license.workspace = true

[lib]
name = "codex_process_hardening"
path = "src/lib.rs"

[lints]
workspace = true

[dependencies]
libc = { workspace = true }

[dev-dependencies]
pretty_assertions = { workspace = true }
chore: move pre_main_hardening() utility into its own crate (#4403) 2025-09-28 14:35:14 -07:00			`[package]`
			`name = "codex-process-hardening"`
chore: add cargo-deny configuration (#7119) - add GitHub workflow running cargo-deny on push/PR - document cargo-deny allowlist with workspace-dep notes and advisory ignores - align workspace crates to inherit version/edition/license for consistent checks 2025-11-24 12:22:18 -08:00			`version.workspace = true`
			`edition.workspace = true`
			`license.workspace = true`
chore: move pre_main_hardening() utility into its own crate (#4403) 2025-09-28 14:35:14 -07:00
			`[lib]`
			`name = "codex_process_hardening"`
			`path = "src/lib.rs"`

			`[lints]`
			`workspace = true`

			`[dependencies]`
			`libc = { workspace = true }`
fix: pre-main hardening logic must tolerate non-UTF-8 env vars (#7749) We received a bug report that Codex CLI crashes when an env var contains a non-ASCII character, or more specifically, cannot be decoded as UTF-8: ```shell $ RUST_BACKTRACE=full RÖDBURK=1 codex thread '<unnamed>' panicked at library/std/src/env.rs:162:57: called `Result::unwrap()` on an `Err` value: "RÃ\xB6DBURK" stack backtrace: 0: 0x101905c18 - __mh_execute_header 1: 0x1012bd76c - __mh_execute_header 2: 0x1019050e4 - __mh_execute_header 3: 0x101905ad8 - __mh_execute_header 4: 0x101905874 - __mh_execute_header 5: 0x101904f38 - __mh_execute_header 6: 0x1019347bc - __mh_execute_header 7: 0x10193472c - __mh_execute_header 8: 0x101937884 - __mh_execute_header 9: 0x101b3bcd0 - __mh_execute_header 10: 0x101b3c0bc - __mh_execute_header 11: 0x101927a20 - __mh_execute_header 12: 0x1005c58d8 - __mh_execute_header thread '<unnamed>' panicked at library/core/src/panicking.rs:225:5: panic in a function that cannot unwind stack backtrace: 0: 0x101905c18 - __mh_execute_header 1: 0x1012bd76c - __mh_execute_header 2: 0x1019050e4 - __mh_execute_header 3: 0x101905ad8 - __mh_execute_header 4: 0x101905874 - __mh_execute_header 5: 0x101904f38 - __mh_execute_header 6: 0x101934794 - __mh_execute_header 7: 0x10193472c - __mh_execute_header 8: 0x101937884 - __mh_execute_header 9: 0x101b3c144 - __mh_execute_header 10: 0x101b3c1a0 - __mh_execute_header 11: 0x101b3c158 - __mh_execute_header 12: 0x1005c5ef8 - __mh_execute_header thread caused non-unwinding panic. aborting. ``` I discovered I could reproduce this on a release build, but not a dev build, so between that and the unhelpful stack trace, my mind went to the pre-`main()` logic we run in prod builds. Sure enough, we were operating on `std::env::vars()` instead of `std::env::vars_os()`, which is why the non-UTF-8 environment variable was causing an issue. This PR updates the logic to use `std::env::vars_os()` and adds a unit test. And to be extra sure, I also verified the fix works with a local release build: ``` $ cargo build --bin codex --release $ RÖDBURK=1 ./target/release/codex --version codex-cli 0.0.0 ``` 2025-12-08 16:00:24 -08:00
			`[dev-dependencies]`
			`pretty_assertions = { workspace = true }`