openclaw - ✅(Solved) Fix openclaw acp accepts input but never returns output; ACP one-shot runs time out with no first event [1 pull requests, 1 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#70699Fetched 2026-04-24 05:54:31
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Participants
Timeline (top)
cross-referenced ×1

After updating to OpenClaw 2026.4.22 (00bd2cf), the openclaw ACP harness still appears broken.

The ACP bridge starts and reports ready, but:

  • openclaw acp client accepts input and then hangs without responding
  • ACP one-shot runs via the embedded ACP runtime produce no output and time out after 120s
  • stream logs contain only start, stall, and final timeout/error events, with no assistant/tool/output events at all

This suggests the failure happens after ACP startup, during turn processing / event emission, not during basic bridge boot.

Error Message

AcpRuntimeError: Timed out after 120000ms

Root Cause

Additional note

This does not look like a pure web UI issue, because the same hang reproduces in local terminal via openclaw acp client.

Fix Action

Fixed

PR fix notes

PR #70815: fix(gateway): emit final chat resync after live agent run completion

Description (problem / solution / changelog)

Summary

On codex/gpt-5.5 (and any harness using the native Codex app-server path), the TUI spins forever after submitting a prompt. Exit + reopen shows the response was actually produced and persisted in the transcript ... it's purely a live-stream finalization gap.

Root cause

The Codex app-server path records the final assistant answer and updates the transcript, but unlike the Codex CLI path, it does not emit a terminal assistant event plus lifecycle:end onto OpenClaw's agent event bus. chat.send is still waiting for that finalization signal, so the live WebSocket stream never closes out and the TUI never renders the final event.

Fix

Conservative fallback in chat.send: after the user-transcript update on an agent run, emit a message-less chat.final broadcast as a UI resync point. The transcript already contains the assistant message, so the client reloads history and goes idle instead of spinning.

Two files, +19 / -1 lines:

  • src/gateway/server-methods/chat.ts ... emit the resync event
  • src/gateway/server-methods/chat.directive-tags.test.ts ... regression assertion for the message-less final

What this does NOT try to do

  • Reimplement reasoning streaming (PR #68982 is already aimed at richer reasoning rendering in the Control UI).
  • Fix the underlying Codex app-server lifecycle emission (that's the deeper, preferred fix; this is a safety net until that lands).

Reproduction

  1. Configure OpenClaw with codex/gpt-5.5 (or codex/gpt-5.4) as primary, think: high.
  2. Open TUI, send any prompt.
  3. Observe indefinite spinner. Exit TUI, reopen. The answer is there in history.

Validation

node scripts/run-vitest.mjs run --config test/vitest/vitest.gateway.config.ts \
  src/gateway/server-methods/chat.directive-tags.test.ts

Result: 54/54 tests pass.

End-to-end: verified live on a reproducing install ... TUI now renders responses cleanly on codex/gpt-5.5 without the exit+reopen dance.

Related

  • Similar stall pattern on ACP: #70699
  • Complementary (not overlapping): #68982 (reasoning streaming in Control UI)

Credits

Patch authored primarily by OpenAI Codex CLI (GPT-5.5) during a live debugging session. Co-authored / verified by Parker Todd Brooks, Lēsa, and Claude Opus 4.7.

Changed files

  • src/gateway/server-methods/chat.directive-tags.test.ts (modified, +10/-1)
  • src/gateway/server-methods/chat.ts (modified, +9/-0)

Code Example

[acp] ready

---

OpenClaw ACP client
Session: <session-id>
Type a prompt, or "exit" to quit.
>

---

> Reply with exactly: pong

---

{"kind":"system_event","text":"Started openclaw session ..."}
{"kind":"lifecycle","phase":"start"}
{"kind":"system_event","text":"openclaw has produced no output for 60s. It may be waiting for interactive input."}
{"kind":"lifecycle","phase":"error","data":{"error":"Timed out after 120000ms"}}
{"kind":"system_event","text":"openclaw run failed: Timed out after 120000ms"}

---

acp startup identity reconcile (renderer=v1): checked=1 resolved=0 failed=1

---

AcpRuntimeError: Timed out after 120000ms

---

openclaw acp client

---

Reply with exactly: pong

---

Reply with exactly: pong
RAW_BUFFERClick to expand / collapse

Summary

After updating to OpenClaw 2026.4.22 (00bd2cf), the openclaw ACP harness still appears broken.

The ACP bridge starts and reports ready, but:

  • openclaw acp client accepts input and then hangs without responding
  • ACP one-shot runs via the embedded ACP runtime produce no output and time out after 120s
  • stream logs contain only start, stall, and final timeout/error events, with no assistant/tool/output events at all

This suggests the failure happens after ACP startup, during turn processing / event emission, not during basic bridge boot.

Environment

  • OpenClaw: 2026.4.22 (00bd2cf)
  • OS: WSL2 / Linux
  • Node: 22.22.2
  • Gateway healthy and reachable
  • ACP bundled runtime installed
  • observed bundled dep log:

What works

openclaw acp --help

Works normally and prints help.

openclaw acp -v

Prints:

[acp] ready

and then remains idle.

openclaw acp client

Starts successfully, shows prompt, e.g.:

OpenClaw ACP client
Session: <session-id>
Type a prompt, or "exit" to quit.
>

So the ACP bridge/client shell itself appears to start correctly.

What fails

1. openclaw acp client never answers prompts

Example:

> Reply with exactly: pong

Observed behavior:

  • prompt is accepted
  • no response is ever produced
  • same behavior for /debug

2. ACP one-shot run via OpenClaw runtime times out

Triggered with:

  • agent: openclaw
  • mode: one-shot ACP run
  • prompt: Reply with exactly: pong

Observed result:

  • child session is created
  • no output is produced for 60s
  • final timeout at 120s

Expected behavior

  • openclaw acp client should answer simple prompts like Reply with exactly: pong
  • ACP one-shot run should emit at least one output event and complete successfully

Actual behavior

  • ACP startup succeeds to a “ready” state
  • client prompt accepts input
  • turn processing appears to hang indefinitely
  • one-shot runtime runs time out with no first output

ACP runtime stream log

The run stream contained only:

{"kind":"system_event","text":"Started openclaw session ..."}
{"kind":"lifecycle","phase":"start"}
{"kind":"system_event","text":"openclaw has produced no output for 60s. It may be waiting for interactive input."}
{"kind":"lifecycle","phase":"error","data":{"error":"Timed out after 120000ms"}}
{"kind":"system_event","text":"openclaw run failed: Timed out after 120000ms"}

No assistant/tool/output/content events were emitted at all.

Gateway log signal

Gateway logs include:

acp startup identity reconcile (renderer=v1): checked=1 resolved=0 failed=1

I do not know whether this is causal, but it is one of the few ACP-related warnings visible near startup.

The final runtime error visible in logs is only the wrapper timeout, e.g.:

AcpRuntimeError: Timed out after 120000ms

No deeper cause is surfaced in the visible logs.

Reproduction steps

  1. Start/update OpenClaw to 2026.4.22
  2. Run:
    openclaw acp client
  3. Enter:
    Reply with exactly: pong
  4. Observe: no response is ever returned

Also reproducible through embedded ACP runtime:

  1. Start ACP one-shot run with agent openclaw
  2. Prompt:
    Reply with exactly: pong
  3. Observe:
    • 60s stall
    • 120s timeout
    • no output events

Additional note

This does not look like a pure web UI issue, because the same hang reproduces in local terminal via openclaw acp client.

extent analysis

TL;DR

The issue with the openclaw ACP harness hanging after startup may be related to the acpx version or the ACP bridge's event emission, and a potential fix could involve checking the compatibility of [email protected] with OpenClaw 2026.4.22 or investigating the ACP bridge's turn processing.

Guidance

  • Verify the compatibility of [email protected] with OpenClaw 2026.4.22 to ensure that the versions are compatible and that there are no known issues with this combination.
  • Investigate the ACP bridge's turn processing and event emission to identify any potential issues that could be causing the hang.
  • Check the Gateway log signal for any errors or warnings related to ACP startup or runtime, such as the acp startup identity reconcile warning, to see if it provides any clues about the cause of the issue.
  • Try to reproduce the issue with a different version of OpenClaw or acpx to see if the problem is specific to the current version.

Example

No specific code example is provided as the issue seems to be related to the compatibility or configuration of the openclaw and acpx versions.

Notes

The issue may be related to the acpx version or the ACP bridge's event emission, but without more information or logs, it is difficult to provide a more specific solution. The Gateway log signal and the ACP runtime stream log may provide more clues about the cause of the issue.

Recommendation

Apply a workaround by checking the compatibility of [email protected] with OpenClaw 2026.4.22 and investigating the ACP bridge's turn processing, as this may help to identify and resolve the issue.

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…

FAQ

Expected behavior

  • openclaw acp client should answer simple prompts like Reply with exactly: pong
  • ACP one-shot run should emit at least one output event and complete successfully

Still need to ship something?

×6

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

Back to top recommendations

TRENDING