openclaw - 💡(How to fix) Fix [Bug]: ACP sessions die immediately with "queue owner unavailable" on local loopback gateway (v2026.4.1, macOS arm64) [1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Every ACP session spawned via sessions_spawn(runtime: "acp") dies within seconds with status=dead summary=queue owner unavailable, preventing all ACP-based coding work on a local loopback gateway (v2026.4.1, macOS arm64, acpx 0.4.0 bundled).

Steps to reproduce

1. Fresh install OpenClaw v2026.4.1 on Mac Mini M4 (macOS 26.3.1, Node v25.8.1)
2. Gateway config: mode=local, bind=loopback, port=18789, auth=token
3. ACP config: enabled=true, backend=acpx, defaultAgent=openclaw
4. ACPX plugin config: permissionMode=approve-all, nonInteractivePermissions=deny, queueOwnerTtlSeconds=30
5. gateway.remote.url=ws://127.0.0.1:18789, gateway.remote.token matches gateway.auth.token
6. From any agent, call sessions_spawn with runtime: "acp", agentId: "openclaw", cwd: "/path/to/repo"
7. Observe session dies immediately in gateway.err.log

Also reproducible with agentId: "codex" — same result.

Additionally, running openclaw acp --verbose directly shows: [acp] ready [acp] gateway disconnected: 1005: The bridge connects but is disconnected by the gateway almost immediately.

Expected behavior

ACP session should stay alive, accept the prompt from sessions_spawn, execute coding work, and return results. This is the documented behavior per https://docs.openclaw.ai/tools/acp-agents.

Actual behavior

Every ACP session dies within seconds. Gateway error log shows:

[plugins] acpx ensureSession repairing dead named session by resuming backend session: session=agent:openclaw:acp:<uuid> cwd=/Users/jeeves/estate-map resumeSessionId=<uuid> status=dead summary=queue owner unavailable

[plugins] acpx ensureSession dead-session resume repair failed; retrying with fresh session owner: session=agent:openclaw:acp:<uuid> cwd=/Users/jeeves/estate-map resumeSessionId=<uuid> error=-32002: Resource not found status=dead summary=queue owner unavailable

This repeats on every ACP session attempt. The acpx backend registers successfully on gateway startup (acpx runtime backend registered + acpx runtime backend ready) but spawned sessions die before processing any work.

OpenClaw version

2026.4.1 (da64a97)

Operating system

macOS 26.3.1 (Darwin 25.3.0, arm64, Mac Mini M4 T8132)

Install method

npm global (Homebrew Node v25.8.1) + Mac app (OpenClaw.app v2026.3.24)

Model

openai-codex/gpt-5.4 (ChatGPT Plus OAuth)

Provider / routing chain

openclaw gateway (local loopback) -> openai-codex OAuth (ChatGPT Plus subscription)

Additional provider/model setup details

Primary model: openai-codex/gpt-5.4 (OAuth, ChatGPT Plus subscription) Fallbacks: openai-codex/gpt-5.3-codex, openai/gpt-5.4, openrouter/anthropic/claude-sonnet-4.6 9 agents configured (main, jim-gold, librarian, hartley, wallace, qa, ui-ux-designer, architect, inspector-dixon) No "codex" agent in agents.list — ACP uses the acpx built-in agent registry

ACPX wrapper script adds /opt/homebrew/bin to PATH because Node.js is not in the default gateway child process PATH on macOS (without this, acpx fails with "env: node: No such file or directory").

Relevant config:

• acp.defaultAgent: "openclaw"
• acp.backend: "acpx"
• plugins.entries.acpx.config.permissionMode: "approve-all"
• plugins.entries.acpx.config.nonInteractivePermissions: "deny"
• plugins.entries.acpx.config.queueOwnerTtlSeconds: 30
• plugins.entries.acpx.config.command: wrapper script pointing to bundled acpx 0.4.0
• gateway.mode: "local"
• gateway.bind: "loopback"
• gateway.auth.mode: "token"
• gateway.remote.url: "ws://127.0.0.1:18789"
• gateway.remote.token: set to match gateway.auth.token

Logs, screenshots, and evidence

Gateway error log pattern (repeats on every ACP session attempt):

2026-04-01T22:59:08.673+01:00 [plugins] acpx ensureSession repairing dead named session by resuming backend session: session=agent:openclaw:acp:07be0abe-d0df-435d-acfb-854a6e382466 cwd=/Users/jeeves/estate-map resumeSessionId=0242032b-81a8-4531-a877-5c898c0679b7 status=dead summary=queue owner unavailable
2026-04-01T22:59:10.022+01:00 [plugins] acpx ensureSession repairing dead named session by resuming backend session: session=agent:openclaw:acp:07be0abe-d0df-435d-acfb-854a6e382466 cwd=/Users/jeeves/estate-map resumeSessionId=0242032b-81a8-4531-a877-5c898c0679b7 status=dead summary=queue owner unavailable
2026-04-01T22:59:28.301+01:00 [plugins] acpx ensureSession repairing dead named session by resuming backend session: session=agent:codex:acp:0c695df9-7ab1-4f09-b53f-d2ade1d61258 cwd=/Users/jeeves/estate-map resumeSessionId=019d4b0f-0274-7412-b14e-ec03890e8026 status=dead summary=queue owner unavailable
2026-04-01T22:59:29.394+01:00 [plugins] acpx ensureSession dead-session resume repair failed; retrying with fresh session owner: session=agent:codex:acp:0c695df9-7ab1-4f09-b53f-d2ade1d61258 cwd=/Users/jeeves/estate-map resumeSessionId=019d4b0f-0274-7412-b14e-ec03890e8026 error=-32002: Resource not found status=dead summary=queue owner unavailable

Direct bridge test:
$ openclaw acp --verbose
[acp] ready
[acp] gateway disconnected: 1005:

What was ruled out:
1. Node PATH (fixed via wrapper — acpx starts and registers successfully)
2. Queue owner TTL (increased from 0.1s default to 30s — no change)
3. nonInteractivePermissions (changed from "fail" to "deny" — no change)
4. Stale session records (cleared sessions.json multiple times — new sessions also die)
5. defaultAgent harness (tried both "codex" and "openclaw" — same error with both)
6. gateway.remote.token (was missing, set to match gateway.auth.token — no change)
7. OpenClaw version (upgraded from 2026.3.28 to 2026.4.1 — no change)
8. openclaw doctor --fix (applied — no change to ACP behavior)

Total dead-session errors logged over 36 hours: 1,100+

Impact and severity

Affected: All ACP-based coding workflows for all agents on this gateway Severity: High — completely blocks the ACP execution lane, which is the designed implementation path for the engineering team (Architect agent dispatches coding work via ACP) Frequency: 100% — every ACP session attempt fails Consequence: Engineering agents cannot use ACP for coding. Workaround is using direct exec (shell commands) instead, which loses the fresh-context-per-slice benefit that ACP provides.

Additional information

The problem existed on v2026.3.28 and persists on v2026.4.1. First observed 2026-03-31 after the engineering team (Architect agent "Carlos") attempted its first real ACP coding session. Cannot confirm a last-known-good version as ACP was not tested before 2026-03-31.

The gateway itself is fully healthy — web UI, Telegram, all 9 agents, heartbeats, compaction, and agent-to-agent messaging all work. Only ACP sessions are affected.

The acpx plugin registers successfully on every gateway restart ("acpx runtime backend registered" + "acpx runtime backend ready") but spawned sessions die immediately.