signal-cli not starting up with gateway (macOS bug?)

what am I missing? am on macOS....

---
tl;dr: Gateway not auto-spawning signal-cli daemon despite autoStart defaulting true. Discord works, Signal needs manual daemon start. Manual workaround works; need gateway-level fix or semi-automated nudge.


Symptoms


1. clawdbot health shows:
- Discord: ok (works immediately on gateway start)
- Signal: failed (unknown) - fetch failed

2. clawdbot channels status shows:
- Signal: enabled, configured, stopped, error: signal daemon not ready (fetch failed)

3. pgrep -fl signal-cli returns nothing (daemon not running)
4. curl http://127.0.0.1:8080/v1/about returns nothing (endpoint unreachable)

---

Gateway Log Evidence


From /Users/zilla/.clawdbot/logs/gateway.log:

[signal] [default] starting provider (http://127.0.0.1:8080)
[signal] signal-cli: INFO  DaemonCommand - Starting daemon in single-account mode for +REDACTED
[signal] signal-cli: INFO  HttpServerHandler - Started HTTP server on /127.0.0.1:8080
[gateway] signal SIGTERM received
[signal] signal-cli: INFO  Shutdown - Received SIGTERM signal, shutting down ...


Pattern: Signal daemon starts successfully, then receives SIGTERM and shuts down. This happens on gateway restarts.

---

Manual Workaround (Confirmed Working)


/opt/homebrew/bin/signal-cli -a +REDACTED daemon --http=127.0.0.1:8080 &


After running this manually:
- clawdbot health shows Signal: ok (22ms)
- Messages flow correctly

---

Findings


1. autoStart should work - Config has cliPath set and no httpUrl, so autoStart defaults true
2. Daemon starts but dies - Logs show successful startup followed by SIGTERM
3. Race condition? - Possible timing issue between gateway expecting daemon ready vs daemon init time
4. No retry mechanism documented - Docs don't mention retry/recovery for daemon startup failures
5. No manual channel restart command - clawdbot channels start signal doesn't exist


---
Was this page helpful?