If you have ever found yourself mindlessly slamming the enter key to approve yet
another read-only file scan while using Codex...
yeah, you're not alone.
I was doing this literally yesterday, just hitting "allow, allow,
allow" for basic search tasks until my finger got tired.
Oh, the classic authorization fatigue.
It-it-it totally defeats the purpose of having a security prompt in the first place
because after the tenth time, you just stop reading what the tool is actually doing.
Exactly.
Which is why this new update, version 0.144.0, is such a big deal.
They've introduced a new app-approval mode called "writes".
And by the way, a quick shout-out to Jellypod for helping make this daily show a
reality.
But yeah, this "writes" mode is designed to solve exactly that problem.
Okay, so "writes" mode.
How does it work?
Does it just, like, guess what's safe and what isn't?
Not quite guessing, no.
It's an explicit configuration.
You open up your config file at ~/.codex/config.toml and you set
default_tools_approval_mode = "writes".
What this does is it splits your tools into two camps.
If a tool is just doing a passive, read-only task-like listing a directory,
reading a file, searching a codebase-it executes instantly.
No prompt, no interruption.
But the moment it tries to, say, modify a file, run a build,
or delete something...
it stops and asks you?
Precisely.
It only prompts you when a tool attempts a modifying action.
So you get a seamless flow for exploration, but a hard stop for actual changes.
That sounds incredibly convenient, but...
as someone who used to work in testing, my immediate thought is: how does Codex
actually *know* a tool is only reading?
Is it inspecting the code, or...
is it just relying on how the tool describes itself?
Ah, you hit the nail right on the head.
And this is the security catch.
It entirely relies on the tool's schema and declarations.
Codex looks at the Model Context Protocol, or MCP, tool definition to see if it's
flagged as a write operation.
So, if you're using a third-party, untrusted, or just a poorly written MCP server,
and they misdeclare a write command as a read...
Codex might run it without asking you.
Oh.
That's a pretty massive loophole if you're pulling in random community MCP servers.
If a server says a tool called delete_database is just a "query" tool...
it just runs?
Technically, yes, if the schema is malformed or maliciously declared.
So, while setting default_tools_approval_mode = "writes" is a massive
quality-of-life upgrade, you really only want to do it if you trust the MCP servers
you have active.
If you're running experimental servers from random GitHub repos,
you might want to stick to the strict "always ask" mode.
Right, keep those guardrails up if you're playing in the wild west.
But speaking of things breaking, let's talk about the immediate follow-up patch,
v0.144.1, because they had to fix a rather nasty macOS packaging bug
right after releasing this, didn't they?
Yeah, v0.144.1 was basically an emergency rescue mission for macOS users.
In the 144.0 release, the companion host binary was completely missing from the
macOS package.
So, if you tried to run in code-mode, the whole thing would just crash instantly
because it couldn't find its partner process.
Oh no!
That's a pretty terminal bug for a release.
Yeah, it-it-it wasn't great.
But what's cool about the fix in 144.1-specifically PR #31913-is
they didn't just repackage the binary.
They actually added an automatic runtime fallback.
So now, if the companion binary is ever missing or fails to launch for some reason,
Codex automatically falls back to an embedded runtime inside the main process.
It prevents the crash entirely and keeps you working.
That's incredibly resilient.
It's always nice when a bug fix actually makes the architecture better instead of
just patching over the hole.
Were there other things in 144.1, or was it just that macOS rescue?
No, they actually snuck in some really nice quality-of-life updates.
For one, interactive authentication for MCP tools is now fully supported without
needing any experimental flags.
They also polished up how usage credits are handled-now you can see granular
usage-limit resets with explicit expiration dates, so you know exactly when your API
limits reload.
Oh, that's huge.
I hate guessing when my token bucket resets.
What about the terminal rendering?
I saw something in the changelog about control characters.
Right, they fixed a terminal rendering bug where raw control characters were
slipping through and messing up the TUI display.
They're now sanitizing those control sequences so your terminal stays clean and
readable instead of getting filled with ANSI escape code garbage.
Thank goodness.
No more weird broken progress bars taking over the screen.
Alright, I'm going to go update my config file to "writes" mode now.
Catch you later, Ethan.
Sounds good.
Talk soon.