#Signal session completely broken after openclaw update

1 messages · Page 1 of 1 (latest)

mellow ginkgo
#

Apr 28 13:49:07 workstation node[3843922]: 2026-04-28T13:49:07.379+02:00 [signal] SSE connection lost, reconnecting in 10s...
Apr 28 13:49:07 workstation node[3843922]: 2026-04-28T13:49:07.379+02:00 [signal] SSE connection lost, reconnecting in 10s...
Apr 28 13:49:07 workstation node[3843922]: 2026-04-28T13:49:07.379+02:00 [signal] SSE connection lost, reconnecting in 10s...
Apr 28 13:49:07 workstation node[3843922]: 2026-04-28T13:49:07.379+02:00 [signal] SSE connection lost, reconnecting in 10s...
Apr 28 13:49:27 workstation node[3843922]: 2026-04-28T13:49:27.382+02:00 [signal] SSE stream error: Error: Signal SSE connection timed out after 10000ms
Apr 28 13:49:27 workstation node[3843922]: 2026-04-28T13:49:27.383+02:00 [signal] SSE connection lost, reconnecting in 10s...
Apr 28 13:49:47 workstation node[3843922]: 2026-04-28T13:49:47.386+02:00 [signal] SSE stream error: Error: Signal SSE connection timed out after 10000ms
Apr 28 13:49:47 workstation node[3843922]: 2026-04-28T13:49:47.386+02:00 [signal] SSE connection lost, reconnecting in 10s...
Apr 28 13:49:52 workstation node[3843922]: 2026-04-28T13:49:52.861+02:00 [signal] signal-cli: WARN ReceiveHelper - Message action failed.
Apr 28 13:49:52 workstation node[3843922]: 2026-04-28T13:49:52.861+02:00 [signal] signal-cli: java.lang.NoClassDefFoundError: org/signal/libsignal/net/UploadTooLargeException
Apr 28 13:49:52 workstation node[3843922]: 2026-04-28T13:49:52.862+02:00 [signal] signal-cli: at org.asamk.signal.manager.internal.SignalDependencies.lambda$getMessageSender$1(SignalDependencies.java:331)
[...]

I get SSE connection lost messages every 10 seconds and sending a message (even /new) gives a UploadTooLargeException. Signal is completely broken after the latest update

kind anvilBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

rain spindleBOT
#

That error doesn’t look like “message too large” — it looks like the running signal-cli install is broken/mismatched. UploadTooLargeException missing at runtime usually means the wrapper/JAR/libs don’t match, or OpenClaw is launching a different signal-cli than the one you updated.

Also: current signal-cli is v0.14.3, and since v0.14.0 the JVM build requires Java 25. (github.com)

Please paste:

openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw config get channels.signal.cliPath
command -v signal-cli
which -a signal-cli
signal-cli --version
java -version
pgrep -af 'signal-cli.*daemon'
#

Immediate likely fix:

openclaw gateway restart

If pgrep still shows old/orphaned signal-cli daemon processes after restart, stop those and restart again. Don’t delete ~/.local/share/signal-cli/data — that’s your linked Signal state.

Docs: https://docs.openclaw.ai/channels/signal

mellow ginkgo
#

which -a signal-cli
signal-cli --version
java -version
/usr/sbin/signal-cli
/usr/bin/signal-cli
/sbin/signal-cli
/bin/signal-cli
signal-cli 0.14.3
openjdk version "25.0.3" 2026-04-21
OpenJDK Runtime Environment (build 25.0.3)
OpenJDK 64-Bit Server VM (build 25.0.3, mixed mode, sharing)

signal-cli send uuid -m "test test test"
java.lang.NoClassDefFoundError: org/signal/libsignal/net/UploadTooLargeException
at org.asamk.signal.manager.internal.SignalDependencies.lambda$getMessageSender$1(SignalDependencies.java:331)
at org.asamk.signal.manager.internal.SignalDependencies.getOrCreate(SignalDependencies.java:391)
at org.asamk.signal.manager.internal.SignalDependencies.getMessageSender(SignalDependencies.java:330)
at org.asamk.signal.manager.helper.SendHelper.handleSendMessage(SendHelper.java:769)
at org.asamk.signal.manager.helper.SendHelper.sendMessage(SendHelper.java:745)
at org.asamk.signal.manager.helper.SendHelper.sendMessage(SendHelper.java:107)
at org.asamk.signal.manager.internal.ManagerImpl.sendMessage(ManagerImpl.java:707)
at org.asamk.signal.manager.internal.ManagerImpl.sendMessage(ManagerImpl.java:814)
at org.asamk.signal.commands.SendCommand.handleCommand(SendCommand.java:264)
at org.asamk.signal.commands.CommandHandler.handleLocalCommand(CommandHandler.java:37)
at org.asamk.signal.App.handleLocalCommand(App.java:281)
at org.asamk.signal.App.handleCommand(App.java:182)
at org.asamk.signal.App.init(App.java:147)
at org.asamk.signal.Main.main(Main.java:57)
Caused by: java.lang.ClassNotFoundException: org.signal.libsignal.net.UploadTooLargeException
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
... 14 more

ur right signal-cli is broken. how would i make it work again without losing data?

rain spindleBOT
#

Yep — good news: this should be recoverable. Your Signal account data is separate from the signal-cli binary, usually here:

~/.local/share/signal-cli/data/

Don’t delete that, don’t re-register, don’t re-link.

Safest fix:

openclaw gateway stop
pgrep -af 'signal-cli.*daemon'

If any daemon is still running, stop that PID.

#

Back up Signal state first:

mkdir -p ~/signal-cli-backups
tar -C ~/.local/share -czf ~/signal-cli-backups/signal-cli-data-$(date +%F-%H%M%S).tgz signal-cli

Then install a clean signal-cli somewhere side-by-side, and point OpenClaw at it:

VERSION=0.14.3
mkdir -p ~/.local/opt/signal-cli-test
cd /tmp
curl -LO "https://github.com/AsamK/signal-cli/releases/download/v${VERSION}/signal-cli-${VERSION}-Linux-native.tar.gz"
tar -xzf "signal-cli-${VERSION}-Linux-native.tar.gz" -C ~/.local/opt/signal-cli-test
#
NEW_CLI="$(find ~/.local/opt/signal-cli-test -type f -name signal-cli | head -1)"
"$NEW_CLI" --version

If that works, test sending with the new binary. If it no longer throws NoClassDefFoundError, pin OpenClaw to it:

openclaw config set channels.signal.cliPath "$NEW_CLI"
openclaw gateway restart
openclaw channels status --probe

The key is: replace the broken install, not the data directory. Avoid register, link, or deleting ~/.local/share/signal-cli/data.

mellow ginkgo
#

i confirmed and it is a bug with the latest signal-cli version

rain spindleBOT
#

Yep — then I’d pin OpenClaw to a known-good older signal-cli binary and leave the Signal data untouched.

GitHub releases currently show v0.14.2 as the latest published release page I can see, with v0.14.1 before it, so if your install reports 0.14.3 I’d roll back to 0.14.2 first, then 0.14.1 if needed. (github.com)

openclaw gateway stop

mkdir -p ~/signal-cli-backups
tar -C ~/.local/share -czf ~/signal-cli-backups/signal-cli-data-$(date +%F-%H%M%S).tgz signal-cli

VERSION=0.14.2
INSTALL_DIR="$HOME/.local/opt/signal-cli-$VERSION"
mkdir -p "$INSTALL_DIR"

cd /tmp
curl -fLO "https://github.com/AsamK/signal-cli/releases/download/v${VERSION}/signal-cli-${VERSION}-Linux-native.tar.gz"