So I- I- I was looking at the pull requests for the new Codex CLI 0.143.0
alpha this morning, and thanks to Jellypod to help make this daily show a reality,
we have a concrete fix for that nasty plugin block we ran into last week.
It turns out, if you tried to run /import on any of your old Claude Code
configurations, the whole thing would just, like, fall over with a massive
validation error.
And it all came down to a single JSON schema failure.
Wait, a schema failure?
Was it actually rejecting valid Claude Code plugins just because of the metadata?
Exactly.
Specifically, in the hooks/hooks.json file inside the plugin package.
Claude Code allows a top-level description field in there to,
you know, explain what the hooks are doing.
But the Codex parser in 0.142.x had this incredibly strict JSON
schema that didn't recognize description at that level.
So, instead of ignoring it, the CLI just threw a validation exception and aborted
the entire import process.
That's wild.
So a harmless piece of documentation in the JSON literally bricked the migration?
I- I mean, that's classic strict validation hurting usability.
Yeah, it- it's the classic "fail shut" approach when you really want to fail open.
But PR 30229, which just landed in the 0.143.0-alpha,
relaxes that parser.
It basically tells the schema validator to ignore extra metadata fields like
description, so the hooks can actually load.
But, Maya, if you're stuck on the stable 0.142 branch right now and can't jump to
the alpha, you don't have to wait.
There's a quick local workaround.
Oh, nice!
Let me guess, we can just manually edit the cache?
Where is Codex actually storing these downloaded plugins?
Precisely.
You want to head into your home directory, and look for
~/.codex/plugins/cache/.
In there, you'll find the directories for each imported plugin.
If you open up the offending plugin's directory, find that hooks/hooks.json file,
and literally just delete the line with the "description" key,
the 0.142 engine will load it up perfectly on the next run.
No more validation crashes.
Okay, that's super easy to hot-patch.
Just ~/.codex/plugins/cache/, find the hook JSON, and strip the
description.
Good to know we have an escape hatch while the alpha stabilizes.
Speaking of stable releases, 0.142.2 quietly dropped some really big
quality-of-life updates for the Model Context Protocol, or MCP.
They've actually enabled MCP tool search by default now.
But the thing I'm most relieved about is the new respect_system_proxy config flag.
If you've ever tried to run Codex behind a corporate firewall on macOS,
you know it's a nightmare with PAC or WPAD configurations.
Oh, tell me about it.
System proxies on macOS are notoriously tricky for CLI tools because they don't
always respect the standard HTTP_PROXY environment variables if the network
uses an automatic proxy discovery script.
Yes!
That's exactly why they added respect_system_proxy.
When you toggle that on in your Codex config, the Go runtime under the hood actually
queries the macOS System Configuration framework directly, so it can resolve those
enterprise PAC files and route your MCP tool search requests properly.
No more silent timeouts when you're on the office VPN.
That is huge for enterprise users.
But, uh, speaking of silent failures and weird resource usage...
we have to talk about issue 29755.
This is an active bug in the Amazon Bedrock provider, and it's a bit of a disaster
if you monitor your log sizes or token usage.
Oh?
What's going on with Bedrock?
Is it a rate-limiting thing?
Worse.
It's a streaming chunk accumulation bug.
So, normally, when you stream a response from Bedrock, the provider is supposed to
send back deltas-you know, just the new tokens as they arrive.
But right now, the Bedrock wrapper is logging these as cumulative snapshots in the
local rollout .jsonl session files.
Meaning, chunk one is "Hello", chunk two is "Hello world", chunk three is "Hello
world from", and so on.
Wait.
So it's writing the entire accumulated history of the response to the log file with
every single new token?
That must make those .jsonl files grow exponentially!
Exactly!
It- it scales quadratically.
If you have a long response, your session log file can balloon to megabytes for a
single prompt.
And the real kicker is how it handles token tracking.
Because it's parsing these cumulative snapshots, the token counting logic is getting
tripped up, especially if you're outputting multi-byte characters like CJK-Chinese,
Japanese, or Korean-where character boundaries get split across chunk boundaries.
It starts miscalculating your actual usage, which can throw off your local token
budget limits.
That is a massive trap.
Especially if you're relying on those local session logs for debugging or auditing.
Is there a fix in the works, or do we have to manually manage these logs?
There's an active fix being tested in the main branch right now that properly
flushes only the deltas to the .jsonl rollouts, but until that's promoted out of
alpha, the best mitigation is to regularly prune your local session history or
temporarily switch your provider backend if you are running massive generation
tasks.
Keep an eye on those file sizes in your workspace directory.
Definitely.
Well, that's a solid heads-up for anyone running heavy Bedrock workflows today.
Alright, good chatting, talk soon!
Yep, catch you next time.