## Summary
Follow-up to #24459 and partial behavioral revert of `a71fc47` / #16699.
- Stop removing `MallocStackLogging*` and `MallocLogFile*` from macOS
pre-main hardening.
- Remove documentation that claims Codex suppresses those allocator
diagnostic controls.
- Retain the shared `remove_env_vars_with_prefix` refactor and existing
`LD_` / `DYLD_` hardening.
## Why
#24459 fixes the composer-corruption problem at the terminal stderr
boundary while preserving redirected stderr. With that guard in place,
stripping macOS malloc diagnostic settings is unnecessary and can hide
diagnostics intentionally enabled by callers.
## Validation
- `just fmt`
- `just test -p codex-process-hardening`
- `just argument-comment-lint-from-source -p codex-process-hardening`
- `git diff --check`
## Why
The Linux managed-proxy bridge helpers are long-lived child processes in
the sandbox networking path. Before this change they stayed dumpable and
the network seccomp profile did not block cross-process memory syscalls,
so another same-user process could potentially inspect or modify bridge
memory instead of interacting only through the intended proxy interface.
## What changed
- reuse the shared `codex-process-hardening` helper to mark bridge
helper children non-dumpable before they begin serving
- deny `process_vm_readv` and `process_vm_writev` in the existing
network seccomp filter
## Security impact
Bridge helpers are less exposed to same-user cross-process inspection or
memory writes, which reduces the chance that sandboxed code can
interfere with proxy support processes outside the intended IPC path.
## Verification
- `cargo test -p codex-process-hardening`
- `cargo test -p codex-linux-sandbox`
- attempted `cargo check -p codex-linux-sandbox --target
x86_64-unknown-linux-gnu`; blocked on missing `x86_64-linux-gnu-gcc` on
this macOS host
---------
Co-authored-by: Codex <noreply@openai.com>
Addresses #11555
Problem: macOS malloc stack-logging diagnostics could leak into the TUI
composer and get misclassified as pasted user input.
Solution: Strip `MallocStackLogging*` and `MallocLogFile*` during macOS
pre-main hardening and document the additional env cleanup.
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
```
## Summary
Builds on FreeBSD and OpenBSD were failing due to globally enabled
Linux-specific keyring features and hardening code paths not gated by
OS. This PR scopes keyring native backends to the
appropriate targets, disables default features at the workspace root,
and adds a BSD-specific hardening function. Linux/macOS/Windows behavior
remains unchanged, while FreeBSD/OpenBSD
now build and run with a supported backend.
## Key Changes
- Keyring features:
- Disable keyring default features at the workspace root to avoid
pulling Linux backends on non-Linux.
- Move native backend features into target-specific sections in the
affected crates:
- Linux: linux-native-async-persistent
- macOS: apple-native
- Windows: windows-native
- FreeBSD/OpenBSD: sync-secret-service
- Process hardening:
- Add pre_main_hardening_bsd() for FreeBSD/OpenBSD, applying:
- Set RLIMIT_CORE to 0
- Clear LD_* environment variables
- Simplify process-hardening Cargo deps to unconditional libc (avoid
conflicting OS fragments).
- No changes to CODEX_SANDBOX_* behavior.
## Rationale
- Previously, enabling keyring native backends globally pulled
Linux-only features on BSD, causing build errors.
- Hardening logic was tailored for Linux/macOS; BSD builds lacked a
gated path with equivalent safeguards.
- Target-scoped features and BSD hardening make the crates portable
across these OSes without affecting existing behavior elsewhere.
## Impact by Platform
- Linux: No functional change; backends now selected via target cfg.
- macOS: No functional change; explicit apple-native mapping.
- Windows: No functional change; explicit windows-native mapping.
- FreeBSD/OpenBSD: Builds succeed using sync-secret-service; BSD
hardening applied during startup.
## Testing
- Verified compilation across affected crates with target-specific
features.
- Smoke-checked that Linux/macOS/Windows feature sets remain identical
functionally after scoping.
- On BSD, confirmed keyring resolves to sync-secret-service and
hardening compiles.
## Risks / Compatibility
- Minimal risk: only feature scoping and OS-gated additions.
- No public API changes in the crates; runtime behavior on non-BSD
platforms is preserved.
- On BSD, the new hardening clears LD_*; this is consistent with
security posture on other Unix platforms.
## Reviewer Notes
- Pay attention to target-specific sections for keyring in the affected
Cargo.toml files.
- Confirm pre_main_hardening_bsd() mirrors the safe subset of
Linux/macOS hardening without introducing Linux-only calls.
- Confirm no references to CODEX_SANDBOX_ENV_VAR or
CODEX_SANDBOX_NETWORK_DISABLED_ENV_VAR were added/modified.
## Checklist
- Disable keyring default features at workspace root.
- Target-specific keyring features mapped per OS
(Linux/macOS/Windows/BSD).
- Add BSD hardening (RLIMIT_CORE=0, clear LD_*).
- Simplify process-hardening dependencies to unconditional libc.
- No changes to sandbox env var code.
- Formatting and linting: just fmt + just fix -p for changed crates.
- Project tests pass for changed crates; broader suite unchanged.
---------
Co-authored-by: celia-oai <celia@openai.com>
Felipe Coury ·
viyatb-oai ·
Eric Traut ·
Michael Bolin ·
Thomas Klausner ·
Xiao-Yong Jin ·