All communication between Signal and nightwire just suddenly stopped, from both cellphone and laptop, logs look clean

[xinunix]

This is really odd, but I woke up this morning after working with nightwire until late last night and I am no longer able to get responses from nightwire via signal (note to self). Things I have tried:

1. First I checked all of the "obvious" things, docker logs signal-api looked clean, curl http://127.0.0.1:8080/v1/accounts returns my cell phone number, etc.
2. Unpaired nightwire device, unpaired laptop device, re-paired both, still no responses from nightwire from either device.
3. Updated nightwire in-line to 1.5.0, setup signal link fresh, same result no responses from nightwire to messages/commands sent from either device, docker logs still look clean, curl http://127.0.0.1:8080/v1/accounts still returns my cell number.
4. Decided to nuke the nightwire install and start fresh, ran install.sh --uninstall, wiped the install directory, pulled the repo down fresh and ran install.sh, everything looked great, signal-api setup went fine, pairing device worked fine, signal-api running, installer said nightwire was ready but still no messages coming into signal on either device from nightwire (both devices get messages sent from each other as expected).

Here is the current state of docker logs signal-api:

`+ set -e

• [ -z /home/.local/share/signal-cli ]
• usermod -u 1000 signal-api
  usermod: no changes
• groupmod -o -g 1000 signal-api
• [ true != false ]
• echo Changing ownership of /home/.local/share/signal-cli to 1000:1000
• chown 1000:1000 -R /home/.local/share/signal-cli
  Changing ownership of /home/.local/share/signal-cli to 1000:1000
• cat
• cap_prefix=-cap_
• cat /proc/sys/kernel/cap_last_cap
• seq -s ,-cap_ 0 40
• caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40
• [ json-rpc = json-rpc ]
• /usr/bin/jsonrpc2-helper
  time="2026-02-27T17:05:11Z" level=info msg="Updated jsonrpc2.yml"
• [ -n ]
• service supervisor start
  Starting supervisor: supervisord.
• supervisorctl start all
• hostname+ -I
  awk {print $1}
• export HOST_IP=172.17.0.2
• exec setpriv --reuid=1000 --regid=1000 --init-groups --inh-caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40 signal-cli-rest-api -signal-cli-config=/home/.local/share/signal-cli
  time="2026-02-27T17:05:13Z" level=info msg="Started Signal Messenger REST API"
  [GIN] 2026/02/27 - 17:05:20 | 200 | 10.181396ms | 172.17.0.1 | GET "/v1/accounts"
  [GIN] 2026/02/27 - 17:07:00 | 200 | 4.106303ms | 172.17.0.1 | GET "/v1/accounts"`

What else can I do to debug/figure this out? I am at a loss at this point.

**One additional note of possible significance, last night I noticed that messages/commands sent from my laptop to nightwire stopped receiving responses from nightwire, i.e. things like /help just echo in signal but return no results. However at that time messages sent from my phone were still working AND responses from nightwire to those messages/commands were visible on both my laptop and my phone. But if I initiated a message/command from my laptop, no response from nightwire. I worked around it just using my phone through the rest of last night. This morning, my phone started behaving like my laptop was last night. Note I have tested on multiple different networks (home, office, mobile) and the behavior is still the same, even after a clean install.

I am willing to do whatever I need to do to get things running smoothly again, but I am just not sure where to dig in further? Any suggestions would be greatly appreciated!

[HackingDave]

Thanks for the detailed report — this is really helpful. The fact that it degraded progressively (laptop first, then phone) and survived a full reinstall narrows things down significantly.

The key missing piece: we need the nightwire logs, not just the signal-api logs. The signal-api docker logs you shared show the REST API is healthy, but they won't show whether nightwire is actually connecting to the WebSocket or processing messages.

Step 1: Check nightwire logs

# If installed as a systemd service (most common on Linux):
journalctl --user -u nightwire --no-pager -n 100

# Or check the log file directly:
cat ~/nightwire/logs/nightwire.log | tail -100

# If your install directory is elsewhere:
cat $NIGHTWIRE_DIR/logs/nightwire.log | tail -100

What to look for:

• nightwire_starting — confirms the process is running
• account_found — confirms it found your Signal account
• websocket_connecting / websocket_connected — confirms it connected to signal-api
• no_account_for_polling or no_accounts_registered — this would explain everything
• websocket_exception or websocket_error — connection failures
• processing_message — appears when a message is actually received and being handled

If you see websocket_connected but no processing_message entries when you send a message, the problem is on the signal-cli side (inside the container). If you don't see websocket_connected at all, nightwire isn't connecting.

Step 2: Test the signal-cli daemon inside the container

The signal-api container has two processes: the REST API (which is working) and the signal-cli daemon (which actually talks to Signal's servers). The daemon could be dead while the API appears fine:

# Check if the signal-cli daemon is running inside the container
docker exec signal-api supervisorctl status

# Try to receive messages directly via signal-cli
docker exec signal-api signal-cli -a YOUR_PHONE_NUMBER receive

If supervisorctl status shows the signal-cli process as stopped/crashed, that's the problem.

Step 3: Test the WebSocket receive endpoint directly

# Install websocat if needed (or use wscat via npm)
# Then test the WebSocket endpoint:
websocat ws://127.0.0.1:8080/v1/receive/YOUR_PHONE_NUMBER

# Or with wscat:
npx wscat -c ws://127.0.0.1:8080/v1/receive/YOUR_PHONE_NUMBER

Send yourself a Signal message while this is connected. If you see JSON data come through, the signal-api WebSocket is working and the issue is in nightwire. If nothing comes through, signal-cli isn't delivering messages.

Step 4: Test sending a message via the API

curl -X POST -H "Content-Type: application/json" \
  http://127.0.0.1:8080/v2/send \
  -d '{"number": "YOUR_PHONE_NUMBER", "recipients": ["YOUR_PHONE_NUMBER"], "message": "test from curl"}'

If this sends successfully and you receive it on your phone, the outbound path works. Combined with step 3, this helps isolate whether it's inbound, outbound, or both.

Step 5: Nuclear option — clean signal-cli data

The progressive failure pattern (laptop → phone) is consistent with signal-cli's session/keys becoming corrupted or invalidated. When you ran the uninstall, if you only wiped the nightwire install directory but didn't fully remove the signal-data directory (or if it was recreated from a Docker volume), the corrupted session data would persist.

# Stop everything
docker stop signal-api

# Check if signal-data still has old data
ls -la ~/nightwire/signal-data/

# If it does, back it up and start fresh
mv ~/nightwire/signal-data ~/nightwire/signal-data.bak
mkdir ~/nightwire/signal-data

# Restart and re-pair
docker start signal-api
# Then run through the QR code pairing again

Most likely cause

Based on your symptoms, my best guess is one of:

1. signal-cli session invalidation — The signal-cli linked device session became stale/invalid. The REST API still works (it's a separate HTTP server), but signal-cli can no longer receive messages from Signal's servers. This would explain why a reinstall didn't fix it if the signal-data directory wasn't fully wiped.

2. signal-cli daemon crashed inside the container — The supervisor-managed signal-cli process inside the Docker container died, but the REST API process is still running. The container appears healthy but can't actually communicate with Signal.

3. Signal rate limiting or trust & safety — If there was heavy automated usage, Signal may have temporarily restricted the account. This is less likely but possible.

Please share the output from Steps 1-4 and we can narrow it down from there!

[HackingDave]

I've also added some additional handling on UUID and better debugging, let me know results, happy to take a look!

[HackingDave]

Hold off, this one is a complex one, working on a fix.

[HackingDave]

This isn't a nightwire issue technically, Signal updated their protocol, and signal-cli is breaking due to it. Fix should be coming out soon.

[HackingDave]

I'm working on a patch for signal-cli until an official release is done. Bug is here: AsamK/signal-cli#1937

[xinunix]

Lengthy kudos below, don't bother reading if you don't have time, nothing of technical relevance here, just sharing some appreciation for your work...

Man Dave, Dave's Jarvis, or whoever I am talking to, just gotta say thank you for making this contribution to the community (nightwire in general, not just this fix). As a 30+ year veteran of the software and technology industry I have literally been watching the AI coding space mostly from the sidelines b/c my gut told me it was going to take automation capabilities like you have built into nightwire to truly have it be something that increases my personal productivity when I am coding (which is unfortunately relatively infrequently these days). The minute I saw your tweet and read the docs I knew I had to give it a try, especially after coming off of an openclaw bender and realizing "now I just really need a tool like openclaw dedicated to coding that can do all of the coding that I am too lazy to do myself, but it has to build quality, well architected and secure code if I am going to be willing to use it". My gut told me Claude + Nightwire was the solution I was looking for. As an opening salvo I used nightwire to create a headless API implementing an idea for an algorithm that I had to create a localized dynamic tennis rating system that I could use to track scores, match results, generate a player dynamic rating system using some math I worked out with another AI model and even predict match results as well as give me probability scores representing the potential for player movement up and down our internal ladder as the season progresses for the middle school tennis team I coach. Think UTR (a world wide tennis rating system) but for local teams (closed loop deterministic system) vs. trying to boil the ocean of being universally applicable to everyone everywhere. I have been working on the core concepts and algorithms for the last 5 years, but never had the motivation or time to turn it into anything more than a semi-fancy spreadsheet. Nightwire provided the motivation I needed and it delivered results beyond expectations! Built it all out in about 2 days wall time (and within budget thanks to your recent release of the ratelimiting features) using a fully autonomous workflow. It's now up and running as an openclaw skill that I can use to record a new match result "Player A beat player B today 6-3, give me their updated dynamic ratings after logging this match", get match stats "how many times has player A beaten a top tier player on the team and by what avg game differential"? "Which players do I need to be watching out for to likely climb or fall on the internal team ladder over the next two weeks?", etc. Nightwire is doing all the things it was designed to do, the way things like this should be done allowing me to focus on the important things in the problem space vs just grinding out code. Truly a breath of fresh air in an area that is too full of hot air these days. Sincerely, Thank You!

[HackingDave]

Thanks brother! Appreciate ya! Sharing what works for me, and always trying to contribute that to help others. Really appreciate the kind words :-)

Just pushed the changes, can you test it for me?

cd ~/nightwire # or wherever they installed
git pull
systemctl --user restart nightwire

[xinunix]

Will do!

[xinunix]

Straight up attempt after doing:

git pull
systemctl --user restart nightwire

and nothing else gives same results, no comms from nightwire to signal from phone or laptop.

I see a new log file in logs, nightwire.log that I don't think was being generated before (only warnings in it are about sqlite_vec_not_available which I would guess isn't related).

Should I try unlinking and linking nightwire again in signal, or I can go ham trying to find a solution? Just don't want to destroy the scene of the crime if we are mid-investigation here...

[HackingDave]

If you can try re-pairing, that would be great. Have it working on mine. Signal-Cli still hasn't done a release yet so this is a patch to keep it working while we wait for a patch

[xinunix]

Ok, so I did another pull (figured it couldn't hurt), re-linked signal and restarted nightwire via systemctl. This time I got a message in Signal client on both phone and laptop that said "[nightwire] Nightwire v2.4.2 started and ready.", this was a change from last run. However all subsequent attempts to do /help or /status from both devices resulted in nothing being returned from nightwire. Also I notice there is a lot more detail in logs/nightwire.log than before. I have attached a digested version of the nightwire.log file, I only excluded a large section of repeated messages that looked like this "2026-02-28 02:31:48,743 [WARNING] 2026-02-28T02:31:48.743463Z [warning ] watchdog_ws_idle [nightwire.bot] idle_seconds=955 threshold=600" but I included a few samples from each end of that stream.

summary.nightwire.log

[HackingDave]

1. Verify signal-cli mode — Make sure your docker-compose.yml is running signal-cli-rest-api in json-rpc mode (not normal mode). The environment variable should be:

   MODE=json-rpc
   

2. Check registration — After re-registering/re-linking your device, send a test message to the registered number from another phone and check the signal-cli container logs:

   docker logs <signal-cli-container> --tail 100
   

   You should see the incoming message in signal-cli's own logs.

3. Test the REST API directly — Try hitting the receive endpoint manually:

   curl -s http://localhost:8080/v1/receive/<your-number>
   

   If this returns [] even after sending a message, signal-cli itself isn't receiving messages (registration/linking issue).

4. Check the WebSocket URL — In your config/settings.yaml, ensure the signal_service URL matches your signal-cli container's address and port, and uses the correct number format (with country code, e.g., +1234567890).

5. Version check — Which version of bbernhard/signal-cli-rest-api are you running? Older versions had WebSocket delivery issues.

We've added additional diagnostic logging in v2.5.9 that will help trace exactly where messages are being dropped. If you pull the latest version, the logs will show envelope_received events for every WebSocket frame with envelope type details.