We've got some interesting security hardening to unpack in today's Codex 0.142.2
release...
specifically around how it handles raw code blocks and remote network requests
before they even touch the model.
Thanks to Jellypod for helping make this daily show a reality.
Yeah, this is...
it's a massive shift in how we think about agentic security,
right?
Because normally you just think, oh, the model checks the code.
But this is- this is happening at the parser level, before the model even gets its
hands on it.
The big one for me is the PowerShell AST safety check.
AST...
that's the Abstract Syntax Tree, for anyone who hasn't had to write a compiler
recently.
Yeah, exactly.
It's how the shell actually- actually parses and understands the structure of your
script.
And what Codex is doing now is, if there's an executable block in that PowerShell
script that the AST classifier...
well, if it can't inspect it.
Say, because of heavy obfuscation or complex, dynamic code generation...
it just stops.
It straight up refuses to run it silently.
Wait, so...
if it's too- if the script is too messy or tries to do something clever like hiding
commands in encoded strings, the terminal just throws an error?
It doesn't just error out and die, it...
it actually halts and demands manual approval.
You get this clear prompt in the terminal saying, "Hey, we couldn't verify this
block, do you actually want to run this?"
Which, as a developer, is a lifesaver.
Because otherwise, you're one weird npm package dependency away from a reverse shell
running on your machine.
Right, because an LLM can easily be tricked into generating or executing some weird
nested PowerShell command that looks harmless but is actually...
you know, downloading a payload.
But wait, what about the other side of this?
The remote image ingress rejection.
That sounds...
a bit aggressive?
No more remote HTTP or HTTPS images?
It sounds aggressive until you think about the plumbing.
Think about Server-Side Request Forgery, or SSRF.
If a model tries to fetch a remote image from
http://malicious-site.com/image.png...
that server now knows your IP, your user agent, maybe even your internal network
structure if it tries to hit a local endpoint.
Like
http://localhost:8080/admin_pannel_screenshot.png.
Oh.
Oh, wow.
Yeah, I didn't even think about local network probing.
It could use the image fetch to scan your internal network.
Exactly.
So now, any remote HTTP or HTTPS image request at ingress is just rejected.
But- but here's the clever part: instead of just failing the whole run,
Codex replaces that image placeholder with a very specific,
clean, model-visible error text.
So the model actually *knows* why it didn't get the image, rather than just getting
a generic socket error and trying again.
Okay, so if I'm building an app that...
I don't know, needs to show a user profile pic, how does that work now?
Am I just stuck?
No, not at all.
You can still use local file paths, and...
and inline data URLs.
Like, base64 encoded images.
Those are processed entirely locally, so there's zero outbound network request.
It keeps the workflow intact without opening up that massive SSRF security hole.
That makes complete sense.
Now, let's talk about the MCP stuff.
That's the Model Context Protocol, right?
They changed how it searches for tools?
Yeah, they did.
So, previously, if you had a ton of MCP tools...
and some developers have massive toolboxes, like dozens of custom tools...
searching through them could get really laggy.
Codex now defaults to using the native tool search of the host system whenever it's
supported.
It's a much smarter, lower-overhead way to locate the right tool without having to
query the entire registry every single time.
And what happens if you're on an older system that doesn't support that native
search?
Does it just break?
No, it- it actually degrades gracefully.
It falls back to the legacy registry search if the native APIs aren't available.
So it's completely backward compatible, but for most modern setups,
it's just...
instant.
Nice.
That leads into the other big enterprise feature in 0.142.2: the proxy support.
This is a massive headache for anyone working behind a corporate firewall.
I remember days of trying to get environment variables like HTTP_PROXY to play nice
with Node and Python tools.
Oh, the proxy wars.
Yeah, it's a nightmare.
But now, if you set respect_system_proxy to true in your config,
Codex will actually query the OS-native proxy resolvers.
We're talking PAC files...
Proxy Auto-Config...
WPAD, and static proxies, natively on both Windows and macOS.
Wait, so...
it actually reads the PAC file?
Like, it evaluates the JavaScript inside the PAC file to find the right proxy route?
Yes!
It hooks directly into the system's network configuration APIs.
So if your IT department has some complex routing rule where internal traffic
bypasses the proxy but external traffic goes through a specific gateway,
Codex just...
respects it.
Automatically.
No more hacking your .bashrc or system registry settings just to get your agent to
talk to the internet.
That is going to save so many enterprise developers from pulling their hair out.
Oh, and speaking of keeping things clean...
did you see the change to the formatters?
Ah, yes!
The quiet formatters.
It's a small thing, but...
so satisfying.
When a formatter run succeeds now, it is completely silent.
No "Successfully formatted file.py" spamming your terminal.
It only speaks up if something actually goes wrong.
Yes!
Thank you.
My terminal output was just a wall of green success checks.
This is much better.
Well, that's a solid wrap on 0.142.2.
Good chatting, talk soon.
Absolutely.
Catch you next time.