* Surface retry-after seconds for plain rate-limit failures libsignal-service's RateLimitException exposes retryAfterMilliseconds for HTTP 413 responses, but signal-cli only forwarded retry-after for ProofRequired (428) failures. Clients had no signal for when it was safe to retry plain rate-limited sends, so every failed retry potentially extended the server-side window. SendMessageResult now carries an optional rateLimitRetryAfterSeconds, populated from the upstream Optional<Long>. JsonSendMessageResult exposes it for RATE_LIMIT_FAILURE type. Text output includes the window when known. Aggregate RateLimitErrorException now carries the real nextAttemptTimestamp (was hardcoded to 0). Closes #1996. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Address review: include proof-required retry-after and ceiling-round millis Codex adversarial review flagged two issues in the phase 1 retry-after plumbing: * Aggregate retry-after ignored proof-required failures. Because isRateLimitFailure is true for proof-required cases but rateLimitRetryAfterSeconds was only populated from plain 413s, an all-proof-required batch (or a mixed batch where the proof-required delay was longer) could flow into outputResult() and produce a RateLimitException(0), telling callers to retry immediately. * Millisecond Retry-After values were truncated by integer division, so 1..999ms became 0 and non-second-aligned values lost up to 999ms. A retry suggested from the floored value can land before the server's real deadline and re-trigger the limit. SendMessageResult.from(...) now populates rateLimitRetryAfterSeconds from either the proof-required seconds or the plain rate-limit ms (converted via ceiling division), giving maxRateLimitRetryAfterSeconds a single source of truth. JsonSendMessageResult.from(...) reads the unified field. New millisToCeilingSeconds helper plus boundary test. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Preserve source compat and document retry-after field change Add a non-canonical 8-arg SendMessageResult constructor that delegates to the canonical form with null retry-after. This keeps source compatibility for any downstream code that constructs the record directly (tests, mocks) without changing the canonical shape. Records permit additional constructors alongside the canonical one. Document the retryAfterSeconds meaning change in the CHANGELOG. The field was previously populated only for proof-required failures; it is now populated whenever the server sends a Retry-After header. The canonical proof-required discriminator is still token != null. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
signal-cli
signal-cli is a commandline interface for the Signal messenger. It supports registering, verifying, sending and receiving messages. signal-cli uses a patched libsignal-service-java, extracted from the Signal-Android source code. For registering you need a phone number where you can receive SMS or incoming calls.
signal-cli is primarily intended to be used on servers to notify admins of important events. For this use-case, it has a daemon mode with JSON-RPC interface (man page) and D-BUS interface (man page). For the JSON-RPC interface there's also a simple example client, written in Rust.
signal-cli needs to be kept up-to-date to keep up with Signal-Server changes. The official Signal clients expire after three months and then the Signal-Server can make incompatible changes. So signal-cli releases older than three months may not work correctly.
Installation
You can build signal-cli yourself or use the provided binary files, which should work on Linux, macOS and Windows. There's also a docker image and some Linux packages provided by the community.
System requirements:
-
at least Java Runtime Environment (JRE) 25
-
native library: libsignal-client
The native libs are bundled for x86_64 Linux (with recent enough glibc), Windows and MacOS. For other systems/architectures see: Provide native lib for libsignal
Install system-wide on Linux [ JVM build ]
See latest version.
VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/AsamK/signal-cli/releases/latest | sed -e 's/^.*\/v//')
curl -L -O https://github.com/AsamK/signal-cli/releases/download/v"${VERSION}"/signal-cli-"${VERSION}".tar.gz
sudo tar xf signal-cli-"${VERSION}".tar.gz -C /opt
sudo ln -sf /opt/signal-cli-"${VERSION}"/bin/signal-cli /usr/local/bin/
Install system-wide on Linux [ GraalVM native build ]
VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/AsamK/signal-cli/releases/latest | sed -e 's/^.*\/v//')
curl -L -O https://github.com/AsamK/signal-cli/releases/download/v"${VERSION}"/signal-cli-"${VERSION}"-Linux-native.tar.gz
sudo tar xf signal-cli-"${VERSION}"-Linux-native.tar.gz -C /opt
sudo ln -sf /opt/signal-cli /usr/local/bin/
You can find further instructions on the Wiki:
Usage
For a complete usage overview please read the man page and the wiki.
Important: The ACCOUNT is your phone number in international format and must include the country calling code. Hence it should start with a "+" sign. (See Wikipedia for a list of all country codes.)
-
Register a number (with SMS verification)
signal-cli -a ACCOUNT registerYou can register Signal using a landline number. In this case, you need to follow the procedure below:
-
Attempt a SMS verification process first (
signal-cli -a ACCOUNT register)- You will get an error
400 (InvalidTransportModeException), this is normal
- You will get an error
-
Wait 60 seconds
-
Attempt a voice call verification by adding the
--voiceswitch and wait for the call:signal-cli -a ACCOUNT register --voice
Registering may require solving a CAPTCHA challenge: Registration with captcha
-
-
Verify the number using the code received via SMS or voice, optionally add
--pin PIN_CODEif you've added a pin code to your accountsignal-cli -a ACCOUNT verify CODE -
Send a message
signal-cli -a ACCOUNT send -m "This is a message" RECIPIENT -
Send a message to a username, usernames need to be prefixed with
u:signal-cli -a ACCOUNT send -m "This is a message" u:USERNAME.000 -
Pipe the message content from another process.
uname -a | signal-cli -a ACCOUNT send --message-from-stdin RECIPIENT -
Receive messages
signal-cli -a ACCOUNT receive
Hint: The Signal protocol expects that incoming messages are regularly received (using daemon or receive
command). This is required for the encryption to work efficiently and for getting updates to groups, expiration timer
and other features.
Storage
The password and cryptographic keys are created when registering and stored in the current users home directory:
$XDG_DATA_HOME/signal-cli/data/
$HOME/.local/share/signal-cli/data/
Building
This project uses Gradle for building and maintaining dependencies. If you have a recent gradle
version installed, you can replace ./gradlew with gradle in the following steps.
-
Checkout the source somewhere on your filesystem with
git clone https://github.com/AsamK/signal-cli.git -
Execute Gradle:
./gradlew build2a. Create shell wrapper in build/install/signal-cli/bin:
./gradlew installDist2b. Create tar file in build/distributions:
./gradlew distTar2c. Create a fat tar file in build/libs/signal-cli-fat:
./gradlew fatJar2d. Compile and run signal-cli:
./gradlew run --args="--help"
Building a native binary with GraalVM (EXPERIMENTAL)
It is possible to build a native binary with GraalVM. This is still experimental and will not work in all situations.
-
Execute Gradle:
./gradlew nativeCompileThe binary is available at build/native/nativeCompile/signal-cli
FAQ and Troubleshooting
For frequently asked questions and issues have a look at the wiki.
License
This project uses libsignal-service-java from Open Whisper Systems:
https://github.com/WhisperSystems/libsignal-service-java
Licensed under the GPLv3: http://www.gnu.org/licenses/gpl-3.0.html