Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Codex ACP subagents fail with ACP_TURN_FAILED (version-independent, 4.15/4.20/4.21 all affected) [3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#70234•Fetched 2026-04-23 07:27:24
View on GitHub
Comments
3
Participants
3
Timeline
8
Reactions
0
Author
Lonobers88Lonobers88
Participants
Lonobers88Lonobers88rafiki270rafiki270steipetesteipete
Timeline (top)
commented ×3subscribed ×3closed ×1mentioned ×1

Codex ACP subagents spawned via sessions_spawn(runtime: "acp", agentId: "codex") fail within 2-3 seconds with AcpRuntimeError: Internal error: code=ACP_TURN_FAILED, even though the underlying Codex CLI works perfectly with OAuth (ChatGPT Pro sub) when invoked directly.

Error Message

{"subsystem":"gateway/ws"} ⇄ res ✗ agent errorCode=UNAVAILABLE errorMessage=AcpRuntimeError: Internal error runId=63c55141-4409-492a-b25b-ddbca2939a2c error=AcpRuntimeError: Internal error: code=ACP_TURN_FAILED

Root Cause

Codex ACP subagents spawned via sessions_spawn(runtime: "acp", agentId: "codex") fail within 2-3 seconds with AcpRuntimeError: Internal error: code=ACP_TURN_FAILED, even though the underlying Codex CLI works perfectly with OAuth (ChatGPT Pro sub) when invoked directly.

Fix Action

Workaround

Using Opus 4.7 as orchestrator without subagents. Long-running work that would benefit from GPT-5.4 delegation is on hold.

Code Example

{"subsystem":"gateway/ws"} ⇄ res ✗ agent errorCode=UNAVAILABLE 
errorMessage=AcpRuntimeError: Internal error 
runId=63c55141-4409-492a-b25b-ddbca2939a2c 
error=AcpRuntimeError: Internal error: code=ACP_TURN_FAILED
RAW_BUFFERClick to expand / collapse

OpenClaw Bug Report — Codex ACP Subagents Fail With ACP_TURN_FAILED

Date: 2026-04-22 Reporter: Lon Obers (@lon1337) OpenClaw version affected: 2026.4.15, 2026.4.20, 2026.4.21 (likely all recent) Codex CLI version: 0.98.0 (@openai/codex) OS: macOS 25.4.0 (arm64) Node: 22.22.0

Summary

Codex ACP subagents spawned via sessions_spawn(runtime: "acp", agentId: "codex") fail within 2-3 seconds with AcpRuntimeError: Internal error: code=ACP_TURN_FAILED, even though the underlying Codex CLI works perfectly with OAuth (ChatGPT Pro sub) when invoked directly.

Reproduction

  1. Fresh codex login via OAuth (ChatGPT Pro plan)
  2. Verify codex exec --model gpt-5.4 --skip-git-repo-check - works via CLI → returns text successfully
  3. Spawn ACP subagent through OpenClaw: sessions_spawn(runtime: "acp", agentId: "codex", task: "say hi")
  4. → Fails in ~2s with ACP_TURN_FAILED and no child output

Observed Behavior

  • CLI direct (with OAuth): works (codex exec returns "Hi Lon")
  • CLI with CODEX_HOME=<harness-auth-bridge-dir>: works
  • ACP subagent via OpenClaw: fails (ACP_TURN_FAILED, 2s, 0 tokens)

Gateway Log

{"subsystem":"gateway/ws"} ⇄ res ✗ agent errorCode=UNAVAILABLE 
errorMessage=AcpRuntimeError: Internal error 
runId=63c55141-4409-492a-b25b-ddbca2939a2c 
error=AcpRuntimeError: Internal error: code=ACP_TURN_FAILED

Repeated pattern: resolving authentication... followed by ACP_TURN_FAILED within 2s. No codex rollout file is created in the harness-auth sessions directory, implying codex never actually starts.

Related Findings (during debugging)

  1. OpenClaw overwrites ~/.codex/auth.json: After codex login stores valid OAuth tokens, gateway start/restart reverts ~/.codex/auth.json to auth_mode: "apikey" with empty tokens. This may be unintentional tamper on an already-valid user auth file.

  2. Agent auth-profiles store had expired tokens: agents/elon/agent/auth-profiles.json contained an openai-codex:default profile expired since 2026-03-28. The openai-codex:[email protected] profile was valid until 2026-05-12. Manually updating the default profile with fresh msn.com tokens did not fix ACP.

  3. Refresh token flow works but tokens unusable by codex CLI: Calling OpenAI's /oauth/token endpoint with grant_type=refresh_token returns new access/id/refresh tokens, but writing them to ~/.codex/auth.json manually results in ERROR: Token data is not available. Only the CLI's own OAuth redirect flow (codex login) produces tokens the CLI can use. This suggests codex CLI does something extra during login (keychain storage?) that the refresh endpoint doesn't replicate.

  4. Bridge architecture: Files openai-codex-cli-bridge-iSYIlfzO.js and openai-codex-cli-auth-BZb3H5Ww.js prepare a per-agent CODEX_HOME with isolated auth.json. The bridge file at agents/main/agent/harness-auth/codex/<hash>/auth.json is created with auth_mode: "chatgpt" but the tokens written don't work when passed via CODEX_HOME.

  5. openclaw.json clobbering: Removing the providers.openai.apiKey field from openclaw.json results in OpenClaw restoring it and saving the edit as openclaw.json.clobbered.<timestamp> backup. Not sure if this is related but unusual behavior.

Environment

  • ChatGPT Pro sub active (plan: pro, [email protected], org Redux org-ryrstoifv9CzmiK7OJ7GLmk2, sub until 2026-05-07)
  • OpenAI API key sk-proj-Mn0yZrL7... has insufficient_quota
  • Both Pro sub and API key configured in OpenClaw

What We Need

  • How should codex ACP harness auth be set up when user has ChatGPT Pro sub?
  • Is there a supported way to point codex ACP at the user's ~/.codex/auth.json?
  • Why does the bridge-prepared auth.json fail even with fresh OAuth tokens including id_token + account_id?
  • Is ACP_TURN_FAILED auth-related or something else in the ACP turn initialization?

Tested Versions

OpenClawCodex ACPCodex CLI direct
2026.4.15❌ fail 2s✅ works
2026.4.20❌ fail 2s✅ works
2026.4.21❌ fail 2s✅ works

Version-independent issue.

Files Referenced

  • ~/.codex/auth.json (overwritten by gateway)
  • ~/.openclaw/agents/elon/agent/auth-profiles.json (had expired default profile)
  • ~/.openclaw/agents/main/agent/harness-auth/codex/06bfb5171eff0241/auth.json (bridge)
  • /tmp/openclaw/openclaw-2026-04-22.log (gateway log)
  • /opt/homebrew/lib/node_modules/openclaw/dist/openai-codex-cli-bridge-iSYIlfzO.js
  • /opt/homebrew/lib/node_modules/openclaw/dist/openai-codex-cli-auth-BZb3H5Ww.js
  • /opt/homebrew/lib/node_modules/openclaw/dist/provider-auth-runtime-BOA0fEzs.js

Workaround

Using Opus 4.7 as orchestrator without subagents. Long-running work that would benefit from GPT-5.4 delegation is on hold.

extent analysis

TL;DR

The most likely fix for the ACP_TURN_FAILED error in OpenClaw with Codex ACP subagents is to correctly configure the authentication setup, ensuring that the Codex CLI's OAuth tokens are properly utilized by the ACP harness.

Guidance

  1. Verify Authentication Configuration: Check that the ~/.codex/auth.json file is not being overwritten by the OpenClaw gateway, and ensure that the authentication mode is set to "chatgpt" with valid OAuth tokens.
  2. Use Valid OAuth Tokens: Confirm that the OAuth tokens used by the Codex CLI are valid and not expired, and try manually updating the tokens in the ~/.codex/auth.json file to see if it resolves the issue.
  3. Check Bridge-Prepared Auth.json: Investigate why the bridge-prepared auth.json file fails to work with fresh OAuth tokens, and consider modifying the bridge architecture to correctly handle the authentication flow.
  4. Test with Different Authentication Modes: Try setting up the Codex ACP harness auth with different authentication modes, such as using the OpenAI API key, to see if it makes a difference in resolving the ACP_TURN_FAILED error.

Example

No specific code example is provided, as the issue seems to be related to the authentication configuration and setup rather than a code-level problem.

Notes

The issue appears to be version-independent, and the problem persists across different OpenClaw and Codex CLI versions. The authentication setup and configuration seem to be the key factors in resolving the ACP_TURN_FAILED error.

Recommendation

Apply a workaround by correctly configuring the authentication setup, ensuring that the Codex CLI's OAuth tokens are properly utilized by the ACP harness, and investigate modifying the bridge architecture to handle the authentication flow correctly.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#agent setup#task chaining#parallel task#integration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING