“Docker Image” Error Was an LLM API Mismatch
The error said 'failed to get Docker image.' The fix was deleting one LLM API parameter.
When the Error Message Points the Wrong Way
We've all been there: an agent stack throws a cryptic error, you spend hours in the wrong subsystem, and the fix ends up being a config change you'd never guess from the message. This week, Tacavar's team hit that exact trap while debugging a PentAGI workflow. Half a day of Docker forensics later, we realized the message was a lie.
The text was "failed to get primary docker image." It sounded like a docker image error. So we did everything Docker: checked the daemon, checked the image name, tried to pull manually. Docker was fine. The image existed. The registry was reachable. Container logs were clean. The fault was somewhere else entirely.
That's the problem with LLM-powered agent stacks: the error message is often a costume, not a fact. It points at the layer where the symptom appeared, not the layer where the cause lived.
The Setup: PentAGI and Docker
We run PentAGI inside Tacavar's infrastructure for internal automation. PentAGI is a multi-agent framework that uses an LLM to plan and execute steps. For this workflow, it needed to spin up a Docker container from a primary image. The agent's plan called for Docker, so the agent asked the LLM to select the image. That call goes through a local proxy (openclaw_proxy.py) and then upstream to the ChatGPT Codex API.
The flow: agent → proxy → Codex → response → agent → Docker. An error at step three surfaces at step five. There's no exception chaining across those boundaries—just a string being handed off.
The root cause was an LLM API compatibility issue. The Codex Responses API rejects the temperature parameter. PentAGI includes it by default, and the API returns a 400. The agent interprets the 400 as "I need this Docker image, and I can't get it," so it emits "failed to get primary docker image." Docker never even got the command.
That's the whole story. Not Docker. Not the image. Not a network problem. A parameter that should have been optional turned a clean API call into a misdirection.
Root Cause: The Codex API Rejects Temperature
The request from PentAGI included temperature in the payload. For most OpenAI models, that's a standard, accepted parameter. The newer Codex Responses API is stricter—it returns a 400 if it sees unsupported fields. It's a textbook LLM API compatibility problem.
We also noticed that response_format, top_p, n, and max_completion_tokens would have failed or been ignored too. The proxy was forwarding everything. Nobody was filtering the payload. We were one bad parameter away from every hard-to-debug error imaginable.
The proxy existed for a reason: to give us a single place to enforce API contracts. But it had no validation rules. It was just a pass-through. That's the gap. The tooling you add to abstract the LLM can also hide the LLM's exact behavior from you.
The One-Line Patch
The fix was a one-line patch to openclaw_proxy.py. Before forwarding the request upstream, strip the unsupported parameter:
payload.pop("temperature", None)
For good measure, we also stripped response_format, top_p, n, and max_completion_tokens for Codex targets. That's what an openclaw proxy fix looks like: five potential 400s eliminated in a few characters.
But the important part isn't the line. It's the fact that we had to find it after chasing a Docker error. Instrumentation on the proxy is what saved us. If we hadn't been logging request bodies, we'd still be checking overlay networks.
Why Agent Stacks Mangle Error Layers
This is the hidden cost of building on agent frameworks. When you compose multiple layers—an LLM client, a tool-use loop, a proxy, an execution engine—errors get wrapped, annotated, and rephrased at every boundary. A 400 from the LLM API gets caught by the agent loop, interpreted as "the tool failed," and returned as a generic Docker error. The result is agent stack error messages that point at the wrong subsystem.
From the LLM's perspective, this wrapping is a feature. It's responding to the narrative it has: "I asked for a Docker image, and I didn't get one." From your perspective, it's a bug. The error is losing information at each hop instead of gaining it.
The model itself makes it worse. When an LLM is asked to report an error, it doesn't know the cause; it knows the context. The context says "Docker image," so the message says "Docker image." The model is doing its best, but the best is a plausible lie.
If you're running an agent stack in production, treat error messages as a hint, not as the primary signal. The real signal lives in the raw request/response logs, especially at the LLM boundary.
How to Debug Through LLM-Wearing Error Clothes
Here's the debug process that works. It'll save you from the next 90-minute detour.
First, when you see an error that mentions a subsystem, directly test that subsystem in isolation. Run the Docker command yourself. If the subsystem works, you've already proved the error is wearing a costume.
Second, always look at the exact payload your agent sent. For us, that meant checking the openclaw proxy request log. The temperature field was right there. One look at the Codex API docs and the case was closed.
Third, instrument your LLM calls. Tacavar's whole thesis is that the LLM call is the most fragile and least visible part of an agent stack. We isolate LLM calls so you can see exactly what went upstream, what came back, and which layer swallowed the error.
Fourth, know your API's parameter schema. LLM API compatibility is not a one-time thing. Providers ship aggressive updates, and a parameter that was valid last week can break today. Build a compatibility shim that rejects or strips unsupported fields before they become runtime errors.
Finally, when you find a workaround, delete it as soon as you can. A proxy that strips temperature is a patch for someone else's bug. The proper fix is to update your agent framework's client or pin the API version. But until then, the one-line patch is your best friend.
For pentagi debugging specifically, the rule is the same: check the LLM call first, not the container logs. The container logs will tell you what the agent believed. The LLM logs will tell you why.
The Generalizable Lesson
The error said "failed to get Docker image." Docker was fine. The real failure was a rejected LLM parameter. That's the state of agentic software today: the most important component in your stack—the LLM call—is also the one most likely to wear a fake error.
When something in an AI agent stack breaks, the first question isn't "what does the error say?" It's "is this really what the error says, or is it an LLM call wearing the error's clothes?" Your debugging process has to start at the LLM boundary, not the subsystem boundary.
Tacavar's infrastructure exists to make that boundary visible. By isolating LLM calls in a separate layer, we make it impossible for a 400 to masquerade as a Docker failure. You run your agent stack. Tacavar runs the part that lies.
Run your own agent stack without error masquerades — see how Tacavar's infrastructure isolates LLM calls at tacavar.com.