Codex 0.144.1 Crashes, Config Fixes, and Safety Rollbacks

Ethan Park

Thanks to Jellypod to help make this daily show a reality. Let's talk about Codex 0.144.1, because if you are running the CLI or the local app-server with that --strict-config safety flag turned on your automated pipelines are probably screaming at you right now. It's a- a- a really specific failure state where Codex Desktop actually poisons the well for the CLI.

Maya

Poisons the well? That sounds a bit dramatic, Ethan, but yeah, it's a mess. It- it- it basically boils down to the shared global config.toml file. When you run the Codex Desktop app, it writes these workspace-specific settings into that global file, specifically under a block like projects."".sandbox_mode. But then, if you run the CLI with --strict-config active, it parses that exact same file, sees those Desktop-specific fields, and just... dies. It throws an unknown configuration field error and crashes on startup.

Ethan Park

Right, the exact error is unknown configuration field projects..sandbox_mode. And- and the reason this is so painful is that --strict-config is designed to fail closed. It's there to make sure you don't have typos in your production configs, but now, just opening the desktop app on your local machine completely breaks your local CLI runs and testing scripts. The desktop app is trying to be helpful by saving your UI preferences, but the parser in the CLI is being way too strict about what it expects to see in that shared TOML.

Maya

So, how do we work around this without, you know, completely uninstalling the Desktop app? Because developers need both.

Ethan Park

Well, the cleanest way is config segregation. You want to isolate your CLI configuration by pointing the CODEX_CONFIG_PATH environment variable to a completely separate, clean TOML file that the Desktop app can't touch. So, in your CI scripts or your local shell profile, you just export CODEX_CONFIG_PATH pointing to, say, ~/.config/codex/cli-config.toml.

Maya

Oh, okay, that makes sense. That way they aren't fighting over the same file. But what if you're in the middle of a run and just need a quick fix?

Ethan Park

If you need a quick fix, you can literally just open up your global config.toml and strip out that entire section. Just delete those lines. Of course, the next time you open the Desktop app, it's going to write them right back in, so it's a temporary band-aid. Alternatively, if you're just running things locally and don't strictly need that strict validation, you can temporarily drop the --strict-config flag from your start commands. But, honestly, setting CODEX_CONFIG_PATH is the right way to go for any kind of stable workflow.

Maya

Right, keep them separated. Now, moving into the rest of the 0.144.x patches, there are a couple of other big stability fixes that dropped right after this. First, they finally sorted out the "failed to spawn" crash in Code Mode by actually bundling the right binaries.

Ethan Park

Yes! In versions 0.144.1 through 0.144.4, they had this packaging omission where the companion binary, codex-code-mode-host, just wasn't being included in the upstream release packages for Linux, macOS, and Windows. So, if you tried to trigger Code Mode, the system would look for that host binary, fail to find it, and the whole process would crash with a "failed to spawn" error. They've finally bundled that executable properly now, so Code Mode actually works out of the box again.

Maya

Which is a massive relief. But the other really interesting change in 0.144.2 is a safety rollback. Specifically, they had to roll back a prompt regression in the Guardian safety engine. Apparently, Guardian was getting a little too aggressive and was actually blocking standard Git pushes to private repositories, treating them as... data exfiltration.

Ethan Park

Yeah, it was treating a standard git push of your code as a security breach. Guardian's LLM-based safety layer was looking at the outbound data transfer and basically saying, "Nope, you can't push this proprietary code outside the local environment," even if it was just your team's standard, authorized private GitHub repo. So, in 0.144.2, they rolled back those over-sensitive prompts to restore normal Git operations.

Maya

It's that classic tension between security and usability. You want a safety engine that prevents exfiltration, but if it stops you from doing a basic git push, developers are just going to disable the safety layer entirely. So, rolling that prompt back was definitely the right call to keep things usable while they refine the rules.

Ethan Park

Absolutely. If you're on any of the early 0.144 builds, definitely upgrade to at least 0.144.2 or later to get those Git operations back to normal and keep Code Mode from crashing. Alright, that's it for this quick update. Talk to you later, Maya.

Maya

Yep, talk soon.