openclaw - 💡(How to fix) Fix [Bug]: Signal channel SSE connection fails persistently with fetch failed every 10 seconds [1 participants]

Q: Expected behavior

**Expected Behavior** SSE connection should stay persistently open. The gateway should maintain a single, long-lived connection to signal-cli's HTTP SSE endpoint without disconnecting every 10 seconds.

openclaw2026-04-05 16:42:18

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.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#61434•Fetched 2026-04-08 02:58:40

View on GitHub

Comments

Participants

Timeline

Reactions

Author

ctohastek

Participants

ctohastek

Timeline (top)

labeled ×1

Signal channel SSE connection fails persistently with fetch failed every 10 seconds Info: Occurs with both JVM and native signal-cli binaries on high-end hardware (Fedora 43, native binary, IPv4 confirmed)

Error Message

/opt/signal-cli-0.14.2/bin/signal-cli --config /var/lib/signal-cli daemon --socket /tmp/signal-cli/socket --tcp 127.0.0.1:8080

Start openclaw gateway (also from systemd; local openclaw --user systemctl is disabled) Log error output appears every 10 seconds; openclaw polls port 8080 and cannot establish a connection

Additional check: Verify binding: ss -tlnp | grep 8080 shows 127.0.0.1:8080.

Signal Configuratoin in OpenClaw (~/.openclaw/openclaw.json):

"channels": {
    "signal": {
      "enabled": true,
      "cliPath": "/usr/bin/signal-cli",
      "httpUrl": "http://127.0.0.1:8080",
      "autoStart": false,
      "receiveMode": "on-start",
      "account": "+1XXXXXXXXXX",
      "dmPolicy": "pairing",
      "allowFrom": [
        "+1XXXXXXXXXX"
      ]
    }
}

(phone numbers redacted)

Log output of openclaw logs --follow 16:22:52+00:00 error gateway/channels/signal {"subsystem":"gateway/channels/signal"} Signal SSE stream error: TypeError: fetch failed 16:22:52+00:00 info gateway/channels/signal {"subsystem":"gateway/channels/signal"} Signal SSE connection lost, reconnecting in 10s...

repeats every 10s

Expected behavior

Expected Behavior SSE connection should stay persistently open. The gateway should maintain a single, long-lived connection to signal-cli's HTTP SSE endpoint without disconnecting every 10 seconds.

Actual behavior

Actual Behavior SSE connection drops every ~10 seconds

Gateway enters reconnect loop

Continuous fetch failed errors in logs

Daemon remains running but connections are reset

Additional Context The native signal-cli binary (GraalVM) starts instantly and uses less memory than the JVM version

Manual curl commands to the daemon work correctly

The problem occurs continuously, not just at startup

This is not the JVM cold start issue documented in #1677 - the problem persists with the native binary on high-end hardware

Docker sandbox environment for OpenClaw is used, but the signal-cli daemon runs directly on the host (not containerized)

OpenClaw version

v2026.4.2

Operating system

Fedora 43

Install method

openclaw installed via install script fetched with curl and executed; openclaw gateway runs out of systemd

Model

anthropic/claude-sonnet-4.5, deepseek chat

Provider / routing chain

local install no proxies or providers

Additional provider/model setup details

none

Logs, screenshots, and evidence

Root Cause

Log output via journalctl -xe -f ------------------------------------------- INFO SocketHandler - Accepted new client connection 621: /127.0.0.1:37786 null WARN SocketHandler - Connection handler failed, closing connection java.lang.AssertionError: java.io.IOException: Connection reset by peer at org.asamk.signal.output.JsonWriterImpl.write(JsonWriterImpl.java:32) at org.asamk.signal.jsonrpc.JsonRpcSender.sendResponse(JsonRpcSender.java:24) at org.asamk.signal.jsonrpc.JsonRpcReader.parseJsonRpcMessage(JsonRpcReader.java:165) at org.asamk.signal.jsonrpc.JsonRpcReader.readMessages(JsonRpcReader.java:67) at org.asamk.signal.jsonrpc.SignalJsonRpcDispatcherHandler.handleConnection(SignalJsonRpcDispatcherHandler.java:205) at org.asamk.signal.jsonrpc.SignalJsonRpcDispatcherHandler.handleConnection(SignalJsonRpcDispatcherHandler.java:72) at org.asamk.signal.jsonrpc.SocketHandler.lambda$new$1(SocketHandler.java:47) at org.asamk.signal.jsonrpc.SocketHandler.lambda$init$1(SocketHandler.java:86) at [email protected]/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545) at [email protected]/java.util.concurrent.FutureTask.run(FutureTask.java:328) at [email protected]/java.util.concurrent.ThreadPerTaskExecutor$ThreadBoundFuture.run(ThreadPerTaskExecutor.java:323) at [email protected]/java.lang.Thread.runWith(Thread.java:1487) at [email protected]/java.lang.VirtualThread.run(VirtualThread.java:456) at [email protected]/java.lang.VirtualThread$VThreadContinuation$1.run(VirtualThread.java:248) Caused by: java.io.IOException: Connection reset by peer at [email protected]/sun.nio.ch.SocketDispatcher.write0(Native Method) at [email protected]/sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:65) at [email protected]/sun.nio.ch.SocketChannelImpl.tryWrite(SocketChannelImpl.java:1442) at [email protected]/sun.nio.ch.SocketChannelImpl.blockingWriteFully(SocketChannelImpl.java:1476) at [email protected]/sun.nio.ch.SocketOutputStream.write(SocketOutputStream.java:61) at [email protected]/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:220) at [email protected]/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:315) at [email protected]/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:320) at [email protected]/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:150) at org.asamk.signal.output.JsonWriterImpl.write(JsonWriterImpl.java:30) ... 13 common frames omitted INFO SocketHandler - Connection 621 closed: /127.0.0.1:37786 null [signal] SSE stream error: TypeError: fetch failed [signal] SSE connection lost, reconnecting in 10s...

Fix Action

Fix / Workaround

Code Example

/opt/signal-cli-0.14.2/bin/signal-cli --config /var/lib/signal-cli daemon --socket /tmp/signal-cli/socket --tcp 127.0.0.1:8080

Start openclaw gateway (also from systemd; local openclaw --user systemctl is disabled)
Log error output appears every 10 seconds; openclaw polls port 8080 and cannot establish a connection

Additional check:
Verify binding: ss -tlnp | grep 8080 shows 127.0.0.1:8080.

2.
Signal Configuratoin in OpenClaw (~/.openclaw/openclaw.json):

    "channels": {
        "signal": {
          "enabled": true,
          "cliPath": "/usr/bin/signal-cli",
          "httpUrl": "http://127.0.0.1:8080",
          "autoStart": false,
          "receiveMode": "on-start",
          "account": "+1XXXXXXXXXX",
          "dmPolicy": "pairing",
          "allowFrom": [
            "+1XXXXXXXXXX"
          ]
        }
    }


(phone numbers redacted)

3. 
Log output of openclaw logs --follow
16:22:52+00:00 error gateway/channels/signal {"subsystem":"gateway/channels/signal"} Signal SSE stream error: TypeError: fetch failed
16:22:52+00:00 info gateway/channels/signal {"subsystem":"gateway/channels/signal"} Signal SSE connection lost, reconnecting in 10s...

repeats every 10s







### Expected behavior


**Expected Behavior**
SSE connection should stay persistently open. The gateway should maintain a single, long-lived connection to signal-cli's HTTP SSE endpoint without disconnecting every 10 seconds.



### Actual behavior

**Actual Behavior**
SSE connection drops every ~10 seconds

Gateway enters reconnect loop

Continuous fetch failed errors in logs

Daemon remains running but connections are reset

**Additional Context**
The native signal-cli binary (GraalVM) starts instantly and uses less memory than the JVM version

Manual curl commands to the daemon work correctly

The problem occurs continuously, not just at startup

**This is not the JVM cold start issue documented in #1677** - the problem persists with the native binary on high-end hardware

Docker sandbox environment for OpenClaw is used, but the signal-cli daemon runs directly on the host (not containerized)

### OpenClaw version

v2026.4.2

### Operating system

Fedora 43

### Install method

openclaw installed via install script fetched with curl and executed; openclaw gateway runs out of systemd

### Model

anthropic/claude-sonnet-4.5, deepseek chat

### Provider / routing chain

local install no proxies or providers

### Additional provider/model setup details

none

### Logs, screenshots, and evidence

RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

Summary

Environment

OpenClaw version: 2026.4.2 (d74a122)
signal-cli versions tested:
- 0.14.1 (JVM / Java)
- 0.14.2 (Linux native / GraalVM, 330MB)
OS: Fedora 43
Hardware: Ryzen 9, 64GB RAM, 2TB SSD (not resource constrained)
Container/sandbox: Docker used to sandbox OpenClaw workspace (unlikely to be related, but noted for completeness)
Connection method: External daemon mode (autoStart: false, httpUrl: http://127.0.0.1:8080)
**Signal-cli setup - signal is running out of systemd (root context) and dropping to signal-cli user for operation
IPv4 binding confirmed: Daemon explicitly bound to 127.0.0.1:8080 (not IPv6)

Problem Description

The SSE connection between OpenClaw and signal-cli fails continuously every ~10 seconds with the following errors in OpenClaw logs: [signal] SSE stream error: TypeError: fetch failed [signal] SSE connection lost, reconnecting in 10s...

signal-cli daemon logs show: java.io.IOException: Connection reset by peer (JVM version)

Steps to reproduce

Start signal-cli from systemd OR manually in IPV4 mode only:

/opt/signal-cli-0.14.2/bin/signal-cli --config /var/lib/signal-cli daemon --socket /tmp/signal-cli/socket --tcp 127.0.0.1:8080

Start openclaw gateway (also from systemd; local openclaw --user systemctl is disabled) Log error output appears every 10 seconds; openclaw polls port 8080 and cannot establish a connection

Additional check: Verify binding: ss -tlnp | grep 8080 shows 127.0.0.1:8080.

Signal Configuratoin in OpenClaw (~/.openclaw/openclaw.json):

"channels": {
    "signal": {
      "enabled": true,
      "cliPath": "/usr/bin/signal-cli",
      "httpUrl": "http://127.0.0.1:8080",
      "autoStart": false,
      "receiveMode": "on-start",
      "account": "+1XXXXXXXXXX",
      "dmPolicy": "pairing",
      "allowFrom": [
        "+1XXXXXXXXXX"
      ]
    }
}

(phone numbers redacted)

repeats every 10s

Expected behavior

Actual behavior

Actual Behavior SSE connection drops every ~10 seconds

Gateway enters reconnect loop

Continuous fetch failed errors in logs

Daemon remains running but connections are reset

Additional Context The native signal-cli binary (GraalVM) starts instantly and uses less memory than the JVM version

Manual curl commands to the daemon work correctly

The problem occurs continuously, not just at startup

This is not the JVM cold start issue documented in #1677 - the problem persists with the native binary on high-end hardware

Docker sandbox environment for OpenClaw is used, but the signal-cli daemon runs directly on the host (not containerized)

OpenClaw version

v2026.4.2

Operating system

Fedora 43

Install method

openclaw installed via install script fetched with curl and executed; openclaw gateway runs out of systemd

Model

anthropic/claude-sonnet-4.5, deepseek chat

Provider / routing chain

local install no proxies or providers

Additional provider/model setup details

none

Logs, screenshots, and evidence

Log output of openclaw logs --follow
-----------------------------------
16:22:52+00:00 error gateway/channels/signal {"subsystem":"gateway/channels/signal"} Signal SSE stream error: TypeError: fetch failed
16:22:52+00:00 info gateway/channels/signal {"subsystem":"gateway/channels/signal"} Signal SSE connection lost, reconnecting in 10s...

(repeats every 10s)


Log output via journalctl -xe -f
------------------------------------------- INFO  SocketHandler - Accepted new client connection 621: /127.0.0.1:37786 null
 WARN  SocketHandler - Connection handler failed, closing connection
 java.lang.AssertionError: java.io.IOException: Connection reset by peer
         at org.asamk.signal.output.JsonWriterImpl.write(JsonWriterImpl.java:32)
         at org.asamk.signal.jsonrpc.JsonRpcSender.sendResponse(JsonRpcSender.java:24)
         at org.asamk.signal.jsonrpc.JsonRpcReader.parseJsonRpcMessage(JsonRpcReader.java:165)
         at org.asamk.signal.jsonrpc.JsonRpcReader.readMessages(JsonRpcReader.java:67)
         at org.asamk.signal.jsonrpc.SignalJsonRpcDispatcherHandler.handleConnection(SignalJsonRpcDispatcherHandler.java:205)
         at org.asamk.signal.jsonrpc.SignalJsonRpcDispatcherHandler.handleConnection(SignalJsonRpcDispatcherHandler.java:72)
         at org.asamk.signal.jsonrpc.SocketHandler.lambda$new$1(SocketHandler.java:47)
         at org.asamk.signal.jsonrpc.SocketHandler.lambda$init$1(SocketHandler.java:86)
         at [email protected]/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
         at [email protected]/java.util.concurrent.FutureTask.run(FutureTask.java:328)
         at [email protected]/java.util.concurrent.ThreadPerTaskExecutor$ThreadBoundFuture.run(ThreadPerTaskExecutor.java:323)
         at [email protected]/java.lang.Thread.runWith(Thread.java:1487)
         at [email protected]/java.lang.VirtualThread.run(VirtualThread.java:456)
         at [email protected]/java.lang.VirtualThread$VThreadContinuation$1.run(VirtualThread.java:248)
 Caused by: java.io.IOException: Connection reset by peer
         at [email protected]/sun.nio.ch.SocketDispatcher.write0(Native Method)
         at [email protected]/sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:65)
         at [email protected]/sun.nio.ch.SocketChannelImpl.tryWrite(SocketChannelImpl.java:1442)
         at [email protected]/sun.nio.ch.SocketChannelImpl.blockingWriteFully(SocketChannelImpl.java:1476)
         at [email protected]/sun.nio.ch.SocketOutputStream.write(SocketOutputStream.java:61)
         at [email protected]/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:220)
         at [email protected]/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:315)
         at [email protected]/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:320)
         at [email protected]/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:150)
         at org.asamk.signal.output.JsonWriterImpl.write(JsonWriterImpl.java:30)
         ... 13 common frames omitted
 INFO  SocketHandler - Connection 621 closed: /127.0.0.1:37786 null
[signal] SSE stream error: TypeError: fetch failed
[signal] SSE connection lost, reconnecting in 10s...

(repeats every 10s)

Impact and severity

Affected: Users, channels Severity: blocks workflows Frequency: always Consequence: Signal is unusable in the Openclaw environment

Additional information

Related Issues Issue #1677 (JVM cold start timeout) - This is different; my problem occurs with native binary and after daemon is already running

Possible Root Cause Hypothesis Since the problem occurs with both JVM and native signal-cli binaries, and IPv4 binding is confirmed, the issue is likely in:

OpenClaw's SSE client implementation (Node.js fetch/EventSource handling)
How OpenClaw maintains the persistent connection to signal-cli's HTTP endpoint
Signal-cli's SSE endpoint behavior with OpenClaw's specific request headers or timing

Request Please investigate the SSE client implementation for the Signal channel. The connection should remain stable, especially when using external daemon mode on capable hardware with confirmed IPv4 binding.

extent analysis

TL;DR

Investigate and adjust the SSE client implementation in OpenClaw to maintain a stable connection with signal-cli's HTTP endpoint.

Guidance

Verify SSE Client Implementation: Review OpenClaw's SSE client code to ensure it correctly handles the EventSource connection and fetch requests to signal-cli's HTTP endpoint.
Check Request Headers and Timing: Inspect the request headers and timing sent by OpenClaw to signal-cli's SSE endpoint to identify potential issues that might cause the connection reset.
Test with Different SSE Endpoint Implementations: If possible, test OpenClaw's SSE client with other SSE endpoint implementations to isolate the issue and determine if it's specific to signal-cli's endpoint.
Adjust Connection Timeout and Reconnect Settings: Consider adjusting the connection timeout and reconnect settings in OpenClaw's SSE client to improve the stability of the connection with signal-cli's endpoint.

Example

No specific code example is provided due to the lack of detailed implementation information in the issue description.

Notes

The issue might be related to the specific implementation details of OpenClaw's SSE client or signal-cli's SSE endpoint, which are not fully described in the issue. Further investigation and debugging are necessary to determine the root cause.

Recommendation

Apply a workaround by adjusting the connection timeout and reconnect settings in OpenClaw's SSE client to mitigate the issue until the root cause is identified and fixed.

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?

FAQ

Expected behavior

#installation #tensor shape #autograd error #model save/load #optimization

Still need to ship something?

×6

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

openclaw - 💡(How to fix) Fix [Bug]: Signal channel SSE connection fails persistently with fetch failed every 10 seconds [1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Logs, screenshots, and evidence

Root Cause

Fix Action

Fix / Workaround

Code Example

Bug type

Beta release blocker

Summary

Environment

Problem Description

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING