Persistent sessions become dead immediately (queue owner unavailable) on macOS

[dtimesjp]

Persistent sessions become dead immediately (queue owner unavailable) on macOS

Summary

Persistent acpx sessions are created successfully, but immediately report dead / queue owner unavailable on status checks.

This reproduces outside OpenClaw, so the issue appears to be in acpx persistent session / queue owner health rather than OpenClaw routing.

Environment

• Host: macOS arm64
• Node: v25.8.2
• acpx: 0.3.1
• Workspace cwd used for repro: /Users/macmini16/.openclaw/workspace

What was ruled out

• Anthropic auth missing: ruled out
• Opus unavailable: ruled out (OPUS_OK one-shot confirmed)
• OpenClaw ACP backend unavailable: fixed after npm restore
• Discord thread session-key suffix bug: patched separately (useSuffix: true)
• Claude ACP adapter version: not root cause
  • reproduced with @zed-industries/claude-agent-acp@0.21.x
  • reproduced with @zed-industries/claude-agent-acp@0.23.1
  • reproduced with @agentclientprotocol/claude-agent-acp@0.24.2

Minimal reproduction

1) Ensure a persistent session

cd /Users/macmini16/.openclaw/workspace
/opt/homebrew/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx --format json --verbose claude sessions ensure --name diag-thread

Observed:

{"action":"session_ensured","created":true,"acpxRecordId":"ce03bfd0-1736-4a9a-a36d-32aaed258617","acpxSessionId":"ce03bfd0-1736-4a9a-a36d-32aaed258617","name":"diag-thread"}

2) Immediately check status

cd /Users/macmini16/.openclaw/workspace
/opt/homebrew/lib/node_modules/openclaw/dist/extensions/acpx/node_modules/.bin/acpx --format json --verbose claude status --session diag-thread

Observed:

{"action":"status_snapshot","status":"dead","pid":17014,"summary":"queue owner unavailable","acpxRecordId":"ce03bfd0-1736-4a9a-a36d-32aaed258617","acpxSessionId":"ce03bfd0-1736-4a9a-a36d-32aaed258617"}

Additional observations

• sessions ensure succeeds repeatedly.
• status reports dead immediately after creation.
• Downstream OpenClaw logs show matching symptoms:
  • acpx ensureSession replacing dead named session
  • summary=queue owner unavailable
• This suggests either:
  1. queue owner process exits immediately after session creation, or
  2. queue owner health probe incorrectly marks a live owner as dead.

Why this matters

OpenClaw ACP thread-bound persistent sessions depend on acpx persistent session health.
As a result, thread-bound ACP sessions are currently unstable, even though one-shot ACP runs work.

Current workaround

Use ACP in one-shot mode only:

• mode: "run"
• thread: false

Request

Please investigate acpx queue owner lifecycle / health probing for newly-created persistent sessions on macOS.
Potential areas:

• queue owner spawn / detach / env handoff
• PID persistence vs actual process liveness
• immediate health probe timing / race
• status health criteria for newly-created sessions

[dtimesjp]

Update from downstream validation: the biggest practical failure mode was not only acpx status=dead itself, but OpenClaw replacing pre-prompt named sessions too aggressively when status returned dead / queue owner unavailable. We patched OpenClaw locally to keep pre-prompt named sessions instead of replacing them in that specific case, and Discord thread-bound ACP sessions then succeeded for at least two consecutive turns. This suggests an integration-sensitive state: before first prompt, a persistent session may legitimately report queue-owner-unavailable because the owner has not been started yet. That state may need to be treated as pre-prompt/uninitialized rather than dead-for-replacement.

[x2x4com]

any solution?

[sambitshankar]

Adding a downstream data point with the opposite failure mode in the same code path. We're seeing the inverse of the symptom this issue describes: instead of queue owners dying when they shouldn't, we see queue owners accumulating without cleanup during normal multi-turn conversation.

Symptom

A persistent ACP session bound to a Telegram topic (via OpenClaw bindings[] with mode: "persistent") works correctly for individual turns, but each interactive turn spawns a fresh claude-agent-acp process pair (npm exec wrapper + node child) without tearing down the previous one. Over time, dozens of orphaned process pairs accumulate. Each pair holds ~100-200 MB resident RAM, so accumulation under sustained conversation produces meaningful memory pressure on any host.

Empirical data (2026-04-06)

• 132 zombie pairs after a ~9-hour auth crash window (each retry attempt during the failure left an orphaned pair behind)
• 52 zombie pairs after only ~1h17m of normal post-recovery conversation (~one new pair per turn, no failures involved — pure steady-state leak)
• Killing the 52 zombies recovered ~5.4 GB of resident RAM (~104 MB per pair on average)
• All zombie pairs showed sub-second CPU usage after spawn — they were idle, not crunching
• lsof against the session stream files showed no file activity from the orphaned pairs — they were doing nothing

Environment

• OpenClaw 2026.4.2 (commit d74a122)
• acpx 0.4.0 (bundled in @openclaw/acpx@2026.4.1-beta.1)
• @zed-industries/claude-agent-acp@0.21.0
• Claude Code CLI 2.1.92
• macOS arm64
• Telegram channel adapter, channels.telegram.threadBindings.spawnAcpSessions=true
• plugins.entries.acpx.config.permissionMode=approve-all, pluginToolsMcpBridge=true
• Persistent binding via openclaw.json bindings[] with mode: "persistent" and cwd set per topic

Why this may be the same root cause

@dtimesjp's diagnosis above ("OpenClaw replacing pre-prompt named sessions too aggressively when status returned dead / queue owner unavailable") suggests queue owner liveness detection is buggy in the pre-prompt direction. We're seeing the post-prompt direction: queue owners that should be torn down (TTL elapsed, turn complete) are not being terminated. Both look like the same broken state machine deciding "is this queue owner still relevant" with the wrong answer in both directions.

The acpx queueOwnerTtlSeconds default is 300s (5 min). In our case, 1+ hour-old queue owners are alive and idle, well past any reasonable TTL window. So the TTL-based reaper either isn't running or isn't authoritative.

Workaround

Periodic process-age reaper: a 5-minute cron that kills any claude-agent-acp process older than 15 minutes. The threshold is safe because legitimate ACP turns complete in <60s, and acpx's own queueOwnerTtlSeconds default of 300s is well below it. ~150-line shell script using ps -eo pid,etimes for age detection. Happy to share as a gist if useful for other affected users.

Open questions for maintainers

1. Is queue owner teardown supposed to fire on turn completion, on TTL expiry, or both?
2. Where in acpx (or claude-agent-acp) is the queue owner cleanup code path? Happy to instrument it locally to capture exact failure conditions.
3. Would a queueOwnerMaxAgeSeconds config (hard kill any queue owner older than N seconds regardless of state) be acceptable upstream as a stopgap?