Remote Control op mijn server staat op Ready, maar in de app kan ik niets doen. Zoek in de debuglog uit waarom en herstel het.
Remote Control draait bij veel klanten als vaste dienst op hun server, zodat er altijd een Claude Code-sessie klaarstaat op de telefoon. Soms lijkt alles in orde en werkt er toch niets. Dit artikel gaat over de oorzaak die wij twee keer tegenkwamen en die met herstarten niet weggaat.
Wat zie je precies?
- In de Claude-app opent de sessie niet, of je krijgt "Remote Control disconnected" of "bridged Claude Code process stopped responding mid-turn".
- Op de server meldt de host
Ready, maar metCapacity: 0/32. Er draait dus geen enkele sessie waar je in kunt typen. - In het venster van de dienst staat alleen "Session failed".
- De dienst herstarten helpt niet. De server herstarten ook niet.
Wat is de oorzaak?
In de projectmap van Claude, bijvoorbeeld ~/.claude/projects/-home-jan/, staat een bestand bridge-pointer.json. Daarin staat welke sessie de host bij het starten weer oppakt. Bestaat die sessie aan de kant van Anthropic niet meer, of is hij net mislukt, dan faalt dat oppakken. De sessie die de host bij de start aanmaakt, stopt binnen een seconde. Het bestand blijft staan, dus na elke herstart gebeurt precies hetzelfde.
In de debuglog ziet dat er zo uit:
[bridge:init] reconnectSession(...) failed: 400 Session not found
<<< control_request {"reason":"archived","subtype":"end_session"}
[ERROR] CCRClient: Epoch mismatch (409, reason=unattributed), shutting down
De eerste keer wees het bestand naar een sessie van weken eerder die inmiddels was gearchiveerd. De tweede keer was het bestand vers: het wees naar de sessie die bij de start van dat moment was mislukt. Het is dus niet alleen een probleem van oude bestanden.
Hoe vind je de echte foutmelding?
Het venster van de dienst zegt alleen "Session failed". De reden zie je pas als je de host zelf start met een debuglog. Stop eerst de dienst, anders draaien er twee:
systemctl --user stop claude-rc # de naam van jouw dienst
claude rc --verbose --debug-file /tmp/rc-debug.log
claude rc is de korte vorm van claude remote-control. Het kindproces schrijft een eigen log, /tmp/rc-debug-<id>.log, en daarin staat de echte reden waarom de sessie stopt. Draai dit in tmux of screen, dan loopt het door als je SSH-verbinding wegvalt.
Hoe los je het op?
Zet het bestand opzij en start de dienst opnieuw:
systemctl --user stop claude-rc
cd ~/.claude/projects/-home-jan/
mv bridge-pointer.json bridge-pointer.json.bak
systemctl --user start claude-rc
De host maakt een nieuw bridge-pointer.json aan. Binnen een paar seconden staat er Connected en Capacity: 1/32.
Let op: de omgeving krijgt daarbij een nieuw ID. Kies in de Claude-app de nieuwe omgeving, of scan de QR-code opnieuw. Een oude bladwijzer naar de sessie werkt niet meer.
Waarom je Claude niet zijn eigen dienst laat herstarten
Een tweede valkuil voelt hetzelfde, maar heeft een andere oorzaak. Vraag je in een Remote Control-sessie om "Remote Control even te herstarten", dan herstart Claude de dienst waar hij zelf in draait. Alle lopende sessies stoppen op dezelfde seconde, met exit code 144.
In het journal zie je het verschil:
Stopping …betekent dat iemand om de stop vroeg, bijvoorbeeld Claude zelf.Scheduled restart jobbetekent dat het proces omviel en systemd het opnieuw startte.
Wij hebben het beheerscript van de dienst een controle gegeven. Het weigert te stoppen of te herstarten als het vanuit de dienst zelf wordt aangeroepen:
if grep -q 'claude-rc\.service' /proc/self/cgroup; then
echo "Geweigerd: deze sessie draait zelf in claude-rc.service" >&2
exit 3
fi
Moet de herstart echt, laat hem dan los van de sessie inplannen. De sessie eindigt, maar de dienst komt terug:
systemd-run --user --on-active=3 systemctl --user restart claude-rc
Veelgemaakte fouten
Blijven herstarten. Zolang bridge-pointer.json naar een dode sessie wijst, levert elke herstart hetzelfde resultaat op.
Het bestand weggooien. Zet het opzij met .bak erachter. Dan kun je later nog zien naar welke sessie het wees.
Alleen naar het venster van de dienst kijken. "Session failed" zegt niets over de reden. Die staat in het debuglog van het kindproces.
De oude bladwijzer blijven gebruiken. Na het herstel is het omgevings-ID anders.
Het in de firewall zoeken. De host belt zelf naar buiten, naar Anthropic. Een geblokkeerd IP-adres aan jouw kant raakt SSH of mail, maar niet Remote Control.