exec-server: preserve fs helper CoreFoundation env

[starr-openai]

Summary

• preserve macOS __CF_USER_TEXT_ENCODING when launching the sandboxed fs helper
• keep the fs-helper env narrow; this adds only the CoreFoundation startup var instead of copying the broader MCP stdio baseline
• add focused coverage that the helper keeps that var without admitting HOME

Diagnosis

The sandboxed fs helper is not launched like a normal child process. Exec-server rebuilds its environment from an allowlist, then calls env_clear() before re-execing Codex with --codex-run-as-fs-helper. That helper dispatches before the normal Codex startup path and only needs to boot a small Tokio runtime, read one JSON request from stdin, perform the direct filesystem operation, and write one JSON response.

The reported macOS hang sampled the helper before Rust main, in CoreFoundation initialization while resolving the default text encoding: _CFStringGetUserDefaultEncoding -> getpwuid_r -> notify_register_check -> bootstrap_look_up3 -> mach_msg2_trap. The fs-helper allowlist kept PATH and temp vars for runtime needs, but it dropped macOS __CF_USER_TEXT_ENCODING. Other Codex subprocess launchers that intentionally build a minimal Unix baseline, such as MCP stdio, already preserve that variable.

My read is that stripping __CF_USER_TEXT_ENCODING forced this internal helper down CoreFoundation's fallback user-lookup path, and that lookup intermittently wedged on the affected machine before the helper could read stdin or touch the target file. Preserving only this macOS startup variable avoids that fallback without broadening the fs-helper environment to shell-like vars such as HOME, USER, locale settings, terminal settings, or proxy credentials.

Internal Slack thread omitted from the public PR body.

Validation

• cd codex-rs && just fmt
• git diff --check