Codex stopped before confirming the turn was complete: the fix

The short answer: the exact banner Codex stopped before confirming the turn was complete means OpenClaw aborted the agent's run before the Codex app-server reported turn.completed, so the reply was cut off mid-write and the run shows as aborted. There are two unrelated root causes behind the same string. Cause A: your OpenAI API key is over its billing quota and returns HTTP 429. Cause B: a long turn ran past OpenClaw's completion-idle timeout (default 60000 ms). Fix A is to fund or swap the key. Fix B is to raise codex.appServer.turnCompletionIdleTimeoutMs and restart the gateway.

Why this error is so confusing

The message reads like the model gave up on its own, but it is OpenClaw's wording for "I stopped waiting." The agent answers fine on most turns, then one reply ends abruptly on Slack or Telegram with this banner, and the run is marked aborted. In a Paperclip workspace the same failure can stick the issue in blocked with the heartbeat run repeating a gateway run timed out message.

What makes it genuinely hard is that the same string maps to two failures with opposite fixes. One is a dead billing key — nothing in the config will help, you have to pay. The other is a healthy, authenticated setup that simply needed more patience on a slow turn. Apply the wrong fix and you waste an afternoon: topping up a key that was never out of quota, or raising a timeout when the real problem is a 429.

Cause A: the OpenAI API key is over its billing quota

A "Codex"-labeled agent can actually run on auth_mode=apikey with an OPENAI_API_KEY hitting api.openai.com on metered billing — even when the dashboard shows an openai-codex/ OAuth provider. When that key is out of credit, OpenAI returns HTTP 429 with insufficient_quota, the completion never streams, and OpenClaw surfaces the turn-completion banner.

Fix: fund the key, or swap in a key that has billing headroom. There is no config knob that makes an out-of-quota key pay for inference. If you are unsure which provider the agent is really using, our companion post on OpenClaw Codex OAuth vs. API-key cost logs walks through why the dashboard label and the actual billing path can disagree.

Cause B: completion-idle timeout on long turns

OpenClaw has a completion-idle timeout for Codex turns with a default of 60000 ms (60 seconds). If the final tool call or a reasoning gap runs longer than that with no streamed output, OpenClaw aborts the turn before it reaches turn.completed — so the reply is cut off mid-write even though auth is valid and rate limits are fine. This is the case where everything looks healthy and only the big, slow turns break.

Fix (self-hosted): raise the idle timeout in your gateway config and restart the gateway.

# gateway config
codex:
  appServer:
    turnCompletionIdleTimeoutMs: 240000   # 3-5 min range; default is 60000

A value in the 180000–300000 ms range (3 to 5 minutes) gives a long tool call or a reasoning gap room to finish before OpenClaw gives up. The tradeoff is honest: a higher timeout means a genuinely stuck turn takes longer to surface as a failure. Pick the low end of the range unless you routinely run long turns.

How to tell the two causes apart

What you observe	Most likely cause	Fix
Even short, simple turns fail with the banner	A — over-quota key	Fund or swap the API key
A real chat completion test returns HTTP 429 insufficient_quota	A — over-quota key	Fund or swap the API key
Model list returns 200 but completions still fail	A — quota is dead, list is unmetered	Test a completion, then fund the key
Auth valid, rate limits low, only long/complex turns fail	B — completion-idle timeout	Raise turnCompletionIdleTimeoutMs, restart gateway

Step-by-step: diagnose then fix

1) Test a real completion with the key (rules in or out Cause A)

Do not test the model list — it lies. Send one actual chat completion with the exact OPENAI_API_KEY the agent uses. If it returns HTTP 429 with insufficient_quota, you have Cause A and you are done diagnosing.

# A 429 here means the key is over quota - completions are metered, the list is not.
curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"ping"}],"max_tokens":1}'

2) If the completion succeeds, look at which turns fail

A clean completion plus low rate-limit usage points to Cause B. Confirm the pattern: short replies go through, and the banner only appears on turns with a long final tool call or a noticeable reasoning gap. That signature is the completion-idle timeout, not billing.

3) Apply the matching fix

For Cause A, fund or swap the key — no config change will help. For Cause B, set codex.appServer.turnCompletionIdleTimeoutMs to a value in the 180000–300000 ms range in your gateway config.

4) Restart the gateway (Cause B only)

The new timeout is not live until the gateway reloads its config. Restart it and let the Codex app-server come back up before you test again.

Stop babysitting your OpenClaw box

Fix it once — or stop fixing it for good.

Apply the checklist above and keep self-hosting, or skip the maintenance entirely: run your OpenClaw on managed hosting from $6.90/mo, starting with a 7-day free trial. We handle the stale locks, gateway restarts, version upgrades, and uptime — and you can import your existing instance in a couple of minutes. Cancel anytime.

Managed hosting — from $6.90/mo Your own hosted OpenClaw instance with automatic restarts and version upgrades. Starts with a 7-day free trial — import your current setup, keep your channels, cancel anytime.

$199 managed setup — optional Prefer we do it for you? One workspace configured end-to-end: first-run config, one 30-minute onboarding/debug session, and a 7-day follow-up. Limited weekly slots.

• Managed hosting handles stale .jsonl.lock files, gateway restarts, and version upgrades for you
• Import your existing OpenClaw setup in minutes — keep your channels and configuration
• The optional $199 setup is scoped: no custom development, enterprise/SRE support, or unsupported self-hosting repair

If you would rather compare options first, review OpenClaw cloud hosting or see the best OpenClaw hosting options before deciding.

Run it on managed hosting — from $6.90/mo Prefer we set it up? $199 managed setup See managed OpenClaw hosting

Result verification

• A real chat completion with the agent's key now returns a normal 200, not 429.
• The previously failing long turn now completes and posts a full reply instead of cutting off.
• The run shows turn.completed rather than aborted.
• On Slack or Telegram, the reply arrives whole — no trailing banner.
• In a Paperclip workspace, the issue no longer sticks in blocked with a repeating gateway-timeout message.

Edge cases and judgment calls

The dashboard says OAuth but billing is metered

A provider shown as openai-codex/ can still resolve to an auth_mode=apikey path with an OPENAI_API_KEY against metered billing. Trust the completion test over the dashboard label when diagnosing a 429.

You raised the timeout but still see the banner on short turns

Then you almost certainly have Cause A, not Cause B. A timeout fix cannot rescue an over-quota key. Go back and run the completion test.

You set the value but never restarted

The config change is inert until the gateway reloads. Restarting is part of the fix, not an optional extra.

You set the timeout very high

A 3-5 minute window is usually enough. Going much higher mostly means a truly hung turn takes longer to fail loudly, which is rarely what you want. Stay in the recommended range.

Typical mistakes

• Testing the model-list endpoint and concluding the key is fine — it returns 200 even when the quota is dead.
• Treating the banner as one bug instead of two unrelated causes.
• Raising the timeout when the real problem is a 429 over-quota key.
• Funding the key when the real problem is a long turn crossing the 60-second idle timeout.
• Changing turnCompletionIdleTimeoutMs but forgetting to restart the gateway.

FAQ

What does "Codex stopped before confirming the turn was complete" actually mean?

OpenClaw aborted the run before the Codex app-server reported turn.completed, so the reply was cut off mid-write. The banner does not say why — it is either an over-quota key returning 429 or a long turn crossing the 60000 ms completion-idle timeout.

Why does the model list work but completions still 429?

Listing models is not metered, so it returns 200 even on a dead key. Only completions are billed, which is why you must test a real completion to see the 429.

What should I read next?

If your Codex billing picture is murky, read OpenClaw Codex OAuth cost logs. If you want a path with less gateway-tuning friction, see managed OpenClaw hosting and OpenClaw cloud hosting.