openclaw - 💡(How to fix) Fix Discord ACP sessions fail with ACP_TURN_FAILED under default acpx permissions while direct acpx succeeds [2 comments, 2 participants]

Summary

We hit a reproducible Discord -> OpenClaw -> ACPX/Codex failure where Discord-launched ACP coding sessions failed almost immediately with AcpRuntimeError: Internal error / code=ACP_TURN_FAILED, while the underlying acpx + Codex adapter worked directly on the same host.

The practical fix was to override the bundled ACPX runtime config so non-interactive Discord-launched coding sessions run with full ACPX harness permissions:

openclaw config set plugins.entries.acpx.config.permissionMode approve-all
openclaw config set plugins.entries.acpx.config.nonInteractivePermissions deny
openclaw gateway restart

After that, Discord-session ACP children could spawn successfully and perform real coding-style actions, including shell execution and file writes.

Related/background: #29195 and #28708 appear to describe nearby ACPX permission/silent failure behavior, but this report is the concrete Discord thread/session path we observed on current 2026.4.24.

Environment

• OpenClaw: 2026.4.24 (cbcfdf6)
• Install kind: package/Homebrew global node install path
• macOS: 26.3 arm64
• Node: v22.22.0
• Codex CLI: codex-cli 0.125.0
• Codex ACP adapter: @zed-industries/[email protected]
• Bundled/local ACPX observed: 0.5.3; npm latest checked: [email protected]
• ACP backend: acpx
• Discord plugin enabled and running
• channels.discord.threadBindings.spawnAcpSessions=true

Starting config that failed

Top-level ACP config:

{
  "enabled": true,
  "dispatch": { "enabled": true },
  "backend": "acpx",
  "allowedAgents": ["codex"]
}

ACPX plugin config before the full fix:

{
  "enabled": true,
  "config": {
    "probeAgent": "codex",
    "timeoutSeconds": 120
  }
}

The plugin defaults resolved to permissionMode=approve-reads and nonInteractivePermissions=fail.

Failure symptoms

Discord/requester ACP tasks failed with task state like:

{
  "runtime": "acp",
  "requesterSessionKey": "agent:main:discord:channel:<redacted>",
  "childSessionKey": "agent:codex:acp:<uuid>",
  "status": "failed",
  "error": "Internal error"
}

Gateway log examples:

AcpRuntimeError: Internal error: code=ACP_TURN_FAILED

From the user side, this looked like Discord could start the ACP flow but the coding child died before useful work started. The error surfaced as a generic internal failure, not as a permission/config hint.

Direct adapter check

The underlying ACP adapter itself was not broken. Running the bundled adapter directly succeeded:

/opt/homebrew/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx \
  --timeout 180 --format text codex exec \
  'OpenClaw ACP smoke test. Reply exactly ACP_SMOKE_READY.'

Result:

ACP_SMOKE_READY
[done] end_turn

That narrowed the issue to OpenClaw's embedded ACPX runtime/config path rather than Codex ACP itself.

Workaround/fix applied locally

We configured ACPX explicitly for non-interactive Discord coding sessions:

{
  "enabled": true,
  "config": {
    "probeAgent": "codex",
    "timeoutSeconds": 300,
    "permissionMode": "approve-all",
    "nonInteractivePermissions": "deny",
    "agents": {
      "codex": {
        "command": "npx -y @zed-industries/[email protected]"
      }
    }
  }
}

Then restarted the gateway.

Verification after workaround

After the config change and restart:

• openclaw config validate passed
• Gateway became reachable
• Discord, Codex, and ACPX plugins reported loaded/no plugin error
• Direct ACP smoke passed
• OpenClaw ACP spawn passed with marker OPENCLAW_ACPX_TASK_READY
• Discord-session ACP spawn passed with marker DISCORD_SESSION_ACPX_READY
• Full-access smoke passed: a Discord-session ACP child created a temporary file via shell, verified its contents, and returned DISCORD_ACP_FULL_ACCESS_OK
• openclaw tasks list --runtime acp --status running returned no stuck ACP jobs

Expected behavior

One of these would make the failure mode much easier to operate:

1. For ACPX-backed non-interactive sessions launched from Discord/thread bindings, either default to a config that can actually perform coding tasks (approve-all or an equivalent explicit profile), or
2. fail loudly before spawning when permissionMode=approve-reads + nonInteractivePermissions=fail means writes/exec will likely crash, and surface the remediation to the Discord/requester session, or
3. include a doctor/preflight check that warns: “Discord ACP coding sessions are non-interactive; set plugins.entries.acpx.config.permissionMode=approve-all if you expect file writes or shell commands.”

Actual behavior

The task was accepted, the child ACP session failed shortly after with ACP_TURN_FAILED, and the user-facing/task-level error was just Internal error. The actionable permission/config cause was only discoverable by inspecting logs/source/config and comparing direct acpx execution against the OpenClaw embedded ACPX path.