macOS: LC_ALL forced to C.UTF-8 in codex CLI shell commands (unified exec)

Open 💬 2 comments Opened Jan 16, 2026 by tzanko-matev

What version of Codex is running?

codex-cli 0.84.0

What subscription do you have?

Pro

Which model were you using?

5.2-codex

What platform is your computer?

Darwin 23.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

iTerm2

What issue are you seeing?

When running shell commands via codex-cli on macOS, LC_ALL is forcibly set to C.UTF-8 even if the user’s locale is different. Note that C.UTF-8 is not usually available on MacOS. This happens without user opt-in and affects command behavior that depends on locale. In particular it can lead to various commands printing warning messages. It appears to come from unified exec environment injection.

Steps to Reproduce

On macOS, run Codex CLI (TUI).
Enter prompt:

Run "env | egrep '^(LANG|LC_)'" and report the result

Observe output contains LC_ALL=C.UTF-8.

Expected Result:

LC_ALL should reflect the user’s environment (or be unset), unless explicitly configured by the user or the command.

Actual Result:

LC_ALL is always set to C.UTF-8.

Suspected Cause

Unified exec injects a fixed locale, including LC_ALL=C.UTF-8, for all unified exec processes.

codex-rs/core/src/unified_exec/process_manager.rs:50 (UNIFIED_EXEC_ENV)
codex-rs/core/src/unified_exec/process_manager.rs:486 (applies env)

Workarounds

Disable unified exec for the session: codex --disable unified_exec …
Run locally with ! in the TUI (bypasses unified exec)
Override in the command: LC_ALL= LANG= LC_CTYPE= env | egrep '^(LANG|LC_)'

What steps can reproduce the bug?

On macOS, run Codex CLI (TUI).
Enter prompt:

Run "env | egrep '^(LANG|LC_)'" and report the result

Observe output contains LC_ALL=C.UTF-8.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

pusherofbrooms · 6 months ago

I'm running into this. I use nixpkgs provided bash. My locale output for a login shell is

$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

This looks correct to me. Codex tells me that its related variables are set to:

LANG=en_US.UTF-8
LC_ALL=C.UTF-8

So this seems to be set by codex.

My concern is that pollutes the context and adds unnecessary tokens.

sstklen · 6 months ago

Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

What's happening: codex-rs/core/src/unified_exec/process_manager.rs line ~50: UNIFIED_EXEC_ENV constant hardcodes LC_ALL=C.UTF-8 for all spawned processes. C.UTF-8 is not a valid locale on macOS (only Linux glibc), causing warnings and overriding user locale.

What worked for us:

Remove the LC_ALL=C.UTF-8 entry from UNIFIED_EXEC_ENV. Instead, inherit the user's existing locale environment (LANG, LC_ALL, LC_CTYPE). If UTF-8 safety is needed, only set LC_CTYPE=UTF-8 as fallback when no locale vars are already defined.

// In codex-rs/core/src/unified_exec/process_manager.rs
// Remove LC_ALL=C.UTF-8 from UNIFIED_EXEC_ENV constant.
// Replace with locale-aware logic:

-    ("LC_ALL", "C.UTF-8"),
+    // Do not override LC_ALL — inherit user's locale.
+    // Only set LC_CTYPE as fallback if no locale is configured.

// In the env-application logic (~line 486), add:
+    if std::env::var("LC_ALL").is_err()
+        && std::env::var("LANG").is_err()
+        && std::env::var("LC_CTYPE").is_err()
+    {
+        cmd.env("LC_CTYPE", "UTF-8");
+    }

Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

_Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying._

---
<sub>🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.</sub>