Codex Alpha Regressions: Missing Tools and Windows SSH Timeouts

Ethan Park

Welcome to the show, and thanks to Jellypod to help make this daily show a reality. I'm Ethan Park, here with Maya, and we are diving straight into some breaking bugs today. Maya, if you've updated to the recent `0.142.0-alpha` builds and noticed your local agent workflows suddenly failing on thread handoffs, it is not you. There is a massive regression in `0.142.0-alpha.1` that has completely wiped the `codex_app` thread-management tools from fresh local sessions.

Maya

Wait, wiped them? [skeptical] Like, they're just gone? In stable `0.140.x` and `0.141.0`, those local sessions injected exactly twelve dynamic `codex_app` tools. We're talking core stuff like `create_thread` and `read_thread`. Are you saying that count literally drops to zero?

Ethan Park

Literally zero. [matter-of-fact] It is a total capability-gating failure or a dynamic injection bug. The session starts up, but the tool belt is completely empty. If your agent tries to hand off a thread, it just throws an undefined tool error because the runtime has no idea what `create_thread` even is anymore.

Maya

That is a nightmare for anyone running multi-agent orchestrations locally. [sighs] I mean, if you're managing complex state across multiple threads, this completely breaks the execution loop. What does the session metadata actually show when this happens?

Ethan Park

If you inspect the local session logs and look at `SessionMeta`, you'll see a property called `dynamic_tools_count`. In the broken alpha build, it's explicitly sitting at zero instead of twelve. [short pause]

Maya

Zero. [chuckles] Okay, well, that's a very clear smoking gun. So if anyone is debugging this right now, look for `dynamic_tools_count` in your logs. If it's zero, what's the immediate play? Just roll back?

Ethan Park

Exactly. The immediate, actionable workaround is to downgrade your local environment back to stable `0.141.0`. Do not waste hours trying to manually register those tools in the alpha; the injection pipeline itself is what's broken. Just pin your dependency to `0.141.0` until the team patches the gatekeeper logic in the alpha branch.

Maya

Speaking of alpha regressions, let's talk about what's happening on Windows hosts. If you are running inside a VS Code Remote SSH session on Windows, the bundled `0.142.0-alpha.6` runner is hitting a hard wall. Specifically, a strict fifteen-second pipe-in sandbox connection timeout that completely halts command execution.

Ethan Park

Fifteen seconds? [pauses] That's fifteen thousand milliseconds. In the context of a local network loop or even a slightly latent SSH hop, that is surprisingly easy to hit if the sandbox environment is slow to spin up. What does the actual error look like when it hits that limit?

Maya

It's incredibly frustrating. If you run something like `apply_patch`, the execution block just dies and spits out `windows sandbox failed: timed out`. The runner pipe simply fails to establish a secure connection within that 15000ms window, so the entire action gets aborted. [frustrated]

Ethan Park

Ah, so the host is up, the SSH session is active, but the local sandbox container or process runner can't talk back to the extension fast enough. [thoughtfully] That's a classic I/O initialization bottleneck on Windows file systems, especially over SSH. How do we bypass this runner binary?

Maya

The quick fix right now is manual substitution. You have to locate the bundled extension binary on your remote host and swap it out with a standalone `0.140.0` or `0.141.0` executable. Those older versions don't have the aggressive pipe-in timeout logic, so they'll actually wait for the handshake to complete.

Ethan Park

That's a solid stopgap, but it highlights a broader issue with how Codex validates its environment state. There is a proposal floating around the repo right now for a new `codex doctor` diagnostic utility. The idea is to have it check for what they're calling "durable capability receipts" before running commands.

Maya

Durable capability receipts? [curious] That sounds like a formal verification step. How would that actually prevent these silent failures?

Ethan Park

Right, so instead of the extension assuming the environment is healthy and just blindly throwing commands over the fence, the runner would have to cryptographically or structurally sign off on its capabilities—like verifying the socket connection is open and the twelve core tools are registered—*before* the session is marked active. If a capability receipt is missing or expired, `codex doctor` flags it instantly instead of letting it fail silently mid-workflow. [reflective]

Maya

That would save so much debugging time. [reflective] Instead of finding out your thread handoff failed five minutes into an agent run, you'd get a pre-flight failure warning. Let's hope that gets fast-tracked into the next stable release. For now, stick to `0.141.0` for your local and Remote SSH setups. Thanks for listening, and we'll see you in the next run.

Ethan Park

See you next time. [warmly]