Claude Code Plugin Fixes and Bedrock Log Growth Bugs

Ethan Park

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.

Maya

Wait, a schema failure? Was it actually rejecting valid Claude Code plugins just because of the metadata?

Ethan Park

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.

Maya

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.

Ethan Park

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.

Maya

Oh, nice! Let me guess, we can just manually edit the cache? Where is Codex actually storing these downloaded plugins?

Ethan Park

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.

Maya

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.

Maya

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.

Ethan Park

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.

Maya

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.

Ethan Park

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.

Maya

Oh? What's going on with Bedrock? Is it a rate-limiting thing?

Ethan Park

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.

Maya

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!

Ethan Park

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.

Maya

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?

Ethan Park

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.

Maya

Definitely. Well, that's a solid heads-up for anyone running heavy Bedrock workflows today. Alright, good chatting, talk soon!

Ethan Park

Yep, catch you next time.