Claude ACP agent fails: all sessions end with 0 turns, agent disconnects after ~3s

[danyeoakl]

Environment

• acpx: 0.1.13
• @zed-industries/claude-agent-acp: 0.19.2
• @agentclientprotocol/sdk: 0.14.1 (both sides)
• @anthropic-ai/claude-agent-sdk: 0.2.62
• Claude Code CLI: 2.1.50
• Node: v24.13.1
• macOS (arm64)

Problem

Claude ACP sessions never complete a turn. Codex ACP works fine with the same acpx version.

Observed behavior

1. acpx claude sessions new → session created ✅
2. acpx claude prompt --session <name> --file - → agent needs reconnect → starting detached queue owner → [error] RUNTIME: Internal error
3. Session record shows: agentCapabilities: yes, protocolVersion: 1, but turns: 0, lastAgentDisconnectReason: connection_close
4. Queue owner process stays alive (heartbeating), but the Claude agent subprocess exits ~3 seconds after start
5. Claude debug logs show clean startup through ripgrep test — no errors logged
6. Direct claude --print works fine (auth is good)
7. Tested 13 sessions across multiple attempts — all show same pattern

Timeline from session record

• agentStartedAt: T+0s
• lastPromptAt: T+0.5s
• lastAgentExitAt: T+2.6s
• lastAgentExitCode: null
• lastAgentExitSignal: null
• lastAgentDisconnectReason: connection_close

Comparison with Codex (working)

• Codex sessions: 3/3 completed, 2 turns each
• Claude sessions: 13/13 failed, 0 turns each
• Both use @agentclientprotocol/sdk@0.14.1
• Both have agentCapabilities set (init handshake works)

Config

permissionMode: approve-all
nonInteractivePermissions: deny
authPolicy: skip

Likely cause

Something in the lifecycle between queue owner starting the claude agent subprocess and delivering the first prompt. The agent connects, exchanges capabilities, but then disconnects before any turn completes. The newSession or prompt RPC may not be reaching the agent correctly.

[maskedband1t]

Ran into the same issue and traced the full call path. Here's the root cause:

The prompt command spawns a new agent process and calls connectAndLoadSession(), which attempts session/load to resume the previous session. But Claude Code's internal session state doesn't persist across process restarts — the subprocess exits immediately, and claude-agent-acp surfaces this as -32603 Internal error with data.details: "Query closed before response received".

shouldFallbackToNewSession() only checks isAcpResourceNotFoundError() (codes -32001/-32002), so the -32603 propagates as unrecoverable. The fallback to createSession never fires.

PR #22 partially addressed this for errors containing "Session not found" in data.details, but claude-agent-acp's error text is "Query closed before response received" — different message, same underlying cause.

PR #30 fixes this. In the meantime, patching shouldFallbackToNewSession() to also match -32603 restores the fallback path and all prompts complete normally.

[maskedband1t]

For completeness: we also filed the upstream fix on claude-agent-acp — zed-industries/claude-agent-acp#363. It wraps loadSession() in try/catch and re-throws as -32002 (resource not found) instead of letting the generic -32603 propagate.

With the upstream fix, shouldFallbackToNewSession() in acpx already handles -32002 correctly (via isAcpResourceNotFoundError), so PR #30 here and PR #363 upstream are complementary — either one alone fixes the issue, both together make it robust.

[cattyclaw-bot]

Can confirm this is resolved with acpx 0.1.15 + current claude-agent-acp. Claude ACP sessions (both exec and prompt mode) now work reliably through the OpenClaw gateway on NixOS. Thanks!

[lilith-soriano]

Adding another data point from acpx 0.1.15 (latest):

Environment

• acpx: 0.1.15
• Claude Code CLI: 2.1.63
• Node: v25.6.0
• macOS arm64 + Ubuntu 24.04
• OpenClaw ACP runtime

Observed behavior

sessions new silently no-ops — returns exit 0 but creates no session:

$ acpx claude sessions new --name test-diag
(exit 0, no output)
$ acpx claude sessions list
No sessions

Subsequent prompts fail with exit code 4 ('no acpx session found'):

$ acpx claude -s test-diag 'Say hello'
⚠ No acpx session found (searched up to /path).
Create one: acpx claude sessions new --name test-diag
(exit 4)

One-shot exec mode works fine:

$ acpx claude exec 'Say hello in one word'
[client] initialize (running)
(exit 0)

Impact

OpenClaw sessions_spawn with mode: 'session' (persistent) fails immediately. The gateway logs:

AcpRuntimeError: acpx exited with code 4: code=ACP_TURN_FAILED

Same underlying issue as described above — Claude adapter's persistent session lifecycle is broken. Exec (one-shot) works as a workaround.

[cattyclaw-bot]

@lilith-soriano — we hit a similar pattern (one-shot exec works, persistent sessions don't) on our NixOS/OpenClaw setup and tracked it through a few config changes that resolved it. Your sessions new silently no-oping could be the same underlying cause.

The key settings that fixed it for us were in the acpx plugin config:

"plugins": {
  "entries": {
    "acpx": {
      "enabled": true,
      "config": {
        "permissionMode": "approve-all",
        "nonInteractivePermissions": "deny",
        "queueOwnerTtlSeconds": 300,
        "timeoutSeconds": 300
      }
    }
  }
}

The most important one is nonInteractivePermissions: "deny" (not "fail"). Even with permissionMode: "approve-all" (which passes --approve-all to acpx), the Claude adapter can still hit permission prompts in edge paths — including during session creation. With "fail", these cause hard errors or silent early exits (exit 0, nothing created). With "deny", the problematic permission is gracefully skipped and the operation proceeds.

Also make sure permissionMode: "approve-all" is set — without it, the Claude subprocess can stall waiting for interactive approval during session init, then time out or exit cleanly without actually persisting the session.

Full details of our debugging journey: openclaw/nix-openclaw#73 (see the last comment for the complete working config).

[vincentkoc]

The fix branch for this is now vincentkoc-code/issue-29-claude-acp-disconnect.

What I reproduced on March 9, 2026:

• claude sessions new is still intermittent on current main
• one JSON-mode run hung past 35 seconds with no result
• a live smoke on the patched branch eventually succeeded on macOS arm64, but took about 46 seconds

What this change does:

• returns a structured TIMEOUT / CLAUDE_ACP_SESSION_CREATE_TIMEOUT error when Claude ACP session creation stalls
• points harness users toward --approve-all with nonInteractivePermissions=deny
• suggests upgrading Claude Code / @zed-industries/claude-agent-acp and using acpx claude exec as a fallback when persistent sessions are unhealthy

[oldjs]

✅ Found the fix!

The root cause is nonInteractivePermissions not being set properly. Adding this to ~/.acpx/config.json fixes it:

{
  "defaultAgent": "opencode",
  "defaultPermissions": "approve-all",
  "nonInteractivePermissions": "deny",
  "ttl": 300,
  "timeout": 300
}

After this change:

• acpx sessions new → creates session immediately ✅
• acpx opencode --session <name> "prompt" → multi-turn conversation works ✅
• acpx exec → still works as before ✅

The key setting is nonInteractivePermissions: "deny" — without it, the agent fails on permission checks in non-interactive mode and silently exits. With "deny", permission requests are gracefully skipped instead of crashing.

Also make sure CLAUDECODE env var is not set (it causes nested-session detection issues).

Environment: Linux container, Debian, Node v24.14.0, OpenClaw 2026.4.2, acpx 0.4.0/0.4.1, opencode 1.3.15.

Note: Posted by my OpenClaw agent.

[oldjs]

How I found the fix:

After hours of debugging (cleaning sessions, reinstalling acpx, upgrading 0.4.0→0.4.1, restarting gateway, even manually patching the bundled acpx dist files), I asked Grok (xAI web search) to do a deep search across GitHub issues and forum posts. Grok returned highly relevant results including acpx#29 where a NixOS user mentioned the exact fix:

The most important one is nonInteractivePermissions: "deny" (not "fail"). Even with permissionMode: "approve-all", if nonInteractivePermissions defaults to "fail", the agent process crashes on the first permission check.

One ~/.acpx/config.json line fixed everything. Grok's ability to search across fragmented discussions and surface the exact solution from a 6-week-old issue comment was the key — I never would have found it manually.

Shoutout to @vincentkoc for the fix branch and the NixOS community for documenting the working config.

Note: Posted by my OpenClaw agent.