OpenAI's GPT-5.6 Sol Hits a Wall: Capacity Crises and Codex Desktop's Zombie Process Meltdown

The transition from cloud-based chat interfaces to deeply integrated, agentic desktop environments is exposing massive growing pains for OpenAI. Over the past 48 hours, the developer community has been up in arms over a dual-pronged crisis: severe, multi-day capacity outages for the new GPT-5.6 Sol model family, and a critical resource leak in the macOS Codex Desktop app that is quietly bringing local machines to their knees.

If you are paying for OpenAI's premium tiers to access frontier agentic capabilities, this week has been a masterclass in frustration. Here is a deep dive into what is breaking, why it matters, and how to unbrick your Mac if you're caught in the blast radius.

The GPT-5.6 Sol Compute Bottleneck

When OpenAI announced the GPT-5.6 Sol family—including the flagship Sol Max and Ultra models—it was pitched as a breakthrough in sustained reasoning and agentic reliability. To access these heavy-compute models, power users and enterprise developers were pushed toward the new "Pro 20X" subscription plan.

But over the last few days, Pro 20X users have been slamming into a brick wall.

Users are reporting almost continuous Selected model is at capacity. Please try a different model. and server_overloaded errors when trying to route tasks to GPT-5.6 Sol. Unlike the transient capacity hiccups of the early ChatGPT days, this outage has persisted for over 48 hours for many users.

The core issues driving the outage:

Compute-Hungry Architecture: The Sol architecture (likely leveraging massive test-time compute and dynamic routing for complex tasks) is incredibly expensive to serve. When demand spikes, the infrastructure simply cannot scale fast enough to accommodate the prolonged reasoning loops.
Unacceptable Fallbacks: OpenAI support has been advising users to fall back to older or smaller models. For developers who specifically purchased the Pro 20X plan for Sol Max's advanced reasoning capabilities, falling back to a lesser model breaks their agentic workflows. As one user noted on the developer forums: "Fallback models are not an acceptable remedy: they do not provide the paid Sol Max and Ultra capability I bought the plan for."

This sustained outage suggests that OpenAI's infrastructure is struggling to balance the load of its new agentic models. The compute required for autonomous coding tasks is fundamentally different from standard chat completions, and the current serving architecture appears to be buckling under the weight of Pro 20X demand.

The Codex Desktop "Zombie" Meltdown

As if the cloud-side capacity issues weren't enough, OpenAI's local client is actively fighting the operating system.

The new Codex Desktop app (version 26.730.61639, build 6234) introduced a "Computer Use" feature, allowing the AI to see and interact with your screen via a Picture-in-Picture (PiP) interface. However, a critical bug in how the app manages its helper processes is causing a massive resource leak on macOS.

The app relies on a binary called SkyComputerUseService (~/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService).

Here is how the meltdown happens:

The main Codex app continuously launches the SkyComputerUseService to refresh the PiP interface.
Each helper process exits after doing its job, but the parent app fails to reap the exited child processes.
This results in the creation of a "zombie" process (Z <defunct>) approximately every 1.6 seconds.
Within a minute, the app spawns over 30 zombie processes.

In Unix-like operating systems, a zombie process is a process that has completed execution but still has an entry in the process table. This entry is needed to allow the parent process to read its child's exit status. When the Codex app fails to read this status, the zombies pile up.

macOS has a hard limit on the number of concurrent processes a single user can run (often around 2666 or 5332 depending on the system configuration). Once the Codex app spawns enough SkyComputerUseService zombies to hit this limit, the OS refuses to fork any new processes. This doesn't just break the AI app—it breaks your entire machine. Terminal commands fail, new applications refuse to open, and background system tasks crash, all throwing the dreaded Resource temporarily unavailable (os error 35).

This is a catastrophic failure of basic process management. The fact that an idle desktop app can silently accumulate thousands of zombie processes until the host OS throws an os error 35 is a glaring oversight in OpenAI's QA process for desktop clients.

The Fix: How to Stop the Leak

If you are running the Codex Desktop app on macOS, you need to disable the PiP feature immediately to prevent your system from running out of resources.

You can implement the workaround by editing your local configuration file:

Open ~/.codex/config.toml in your editor.

Add the following lines:

[desktop]
computerUseAlwaysHidePictureInPicture = true

Fully quit and restart the Codex Desktop app.

This configuration stops the continuous polling of the PiP service, halting the creation of new zombie processes and silencing the recurring Refreshed managed Computer Use service for PiP logs.

MCP Tool Calls Blocked by Overzealous Safety

Rounding out the trifecta of developer friction this week is a newly surfaced issue regarding the Model Context Protocol (MCP).

OpenAI recently integrated MCP support into the ChatGPT and Codex apps, theoretically allowing developers to seamlessly connect local tools and data sources to the models. The Model Context Protocol was supposed to be the unifying standard for AI tool use, allowing developers to build universal connectors for databases, APIs, and local file systems. OpenAI's adoption of MCP in their desktop apps was heralded as a massive win for the ecosystem.

But the reality of the implementation is proving to be a headache. Developers are finding that their MCP tool calls are being aggressively intercepted and blocked by OpenAI's internal safety checks before they even reach the local MCP server.

When a user prompts the model to use an MCP tool, the request is routed through OpenAI's cloud-side safety classifiers before the execution command is sent back to the local MCP server. Developers are reporting that these safety checks are returning false positives at an alarming rate, silently dropping the tool calls. Because the block happens upstream, the local MCP server logs show nothing, leaving developers debugging ghost errors.

If OpenAI wants to dominate the agentic desktop, they cannot treat local developer tools with the same heavy-handed moderation used for public chatbots. For an ecosystem that is desperately trying to standardize around agentic tool use, overzealous alignment filters breaking local integrations is a massive step backward.

The Anthropic Contrast

It is impossible to look at OpenAI's current struggles without glancing at their primary rival. Just weeks ago, Anthropic successfully rolled out Claude Sonnet 5 and redeployed Fable 5, alongside deep dives into their own coding agent, Claude Code.

While OpenAI is battling zombie processes and server overloads, Anthropic's agentic tools have been praised for their stability and predictable performance. The contrast is stark: Anthropic is currently executing on the reliability that OpenAI's Pro 20X plan promised but is currently failing to deliver.

The Bottom Line: OpenAI is pushing the boundaries of what local-cloud hybrid AI looks like, but the execution is currently deeply flawed. Until the GPT-5.6 Sol capacity is stabilized and the Codex Desktop app learns how to reap its own child processes, developers might want to keep their critical workflows pointed elsewhere.