Claude Code externe verbindingsproblemen oplossen: symptomen, criteria en oplossingen voor zes soorten verbrekingen

Op afstand met Claude Code werken is niet het meest vervelend als je geen verbinding krijgt, maar als je verbonden bent en dan steeds weer wordt verbroken, en elke keer om een andere reden.

Het woord 'verbroken' dekt eigenlijk zes totaal verschillende storingen. Hun symptomen zijn elk kenmerkend en de oplossingen staan los van elkaar — als je een door netwerkwisseling veroorzaakte lange verbinding die wegvalt behandelt als een machine die in slaap is gevallen, helpt het uitschakelen van slaapstand niet; als je een halfopen verbinding aanziet voor slecht netwerk en wacht, zal het tegen de ochtend niet vanzelf beter worden.

Dit artikel leidt de oorzaak af op basis van wat je daadwerkelijk ziet: voor elke verbreking geeft het de symptomen, hoe je bevestigt dat het die is, en de bijbehorende oplossing. Wil je direct aan de slag, spring dan naar de checklist in de laatste sectie.

Dit artikel gaat alleen over het oplossen van verbindingsstoringen. Hoe je externe toegang opzet, zie Claude Code externe toegang: beheer sessies overal, ook zonder lokale machine, en hoe je de mobiele kant gebruikt, zie Mobiel verbinden met Claude Code: iOS-sessies en goedkeuringstools bekijken.

Vergelijk eerst de symptomen: welke zie je?

Een externe verbinding bestaat uit twee segmenten: de ontwikkelmachine waarop Claude Code draait ←→ het apparaat waarop jij kijkt. Als een van beide segmenten problemen heeft, uit zich dat als 'verbroken', maar de verschijnselen verschillen:

Wat je ziet	Waarschijnlijk is	Spring naar
Sessie blijft plotseling hangen; na opnieuw verbinden blijkt de voortgang ook op dat moment te zijn gestopt	Ontwikkelmachine slaapt / scherm vergrendeld	§1
Verbroken op het moment dat je een lift ingaat, overschakelt naar 4G of van WiFi wisselt	Langdurige verbinding wordt afgebroken	§2
Zodra de lokale terminal wordt gesloten of de lokale machine in slaap valt, wordt de externe verbinding onmiddellijk verbroken	Harde beperking van een screen-mirroring oplossing	§3
Toont online, maar berichten verdwijnen zonder enige foutmelding	Halfopen verbinding	§4
Kan opnieuw verbinden, maar je komt terug in een lege sessie / berichten tijdens de verbreking zijn verdwenen	Opnieuw verbinden heeft de oorspronkelijke sessie niet hervat	§5
Na enkele uren opnieuw verbinden is de sessie verdwenen	Proces opgeruimd en zonder koud herstel	§6

De meest misleidende is de vierde: hij geeft geen foutmelding. De verbindingsstatus is groen, berichten worden verzonden, maar er komt nooit een antwoord — moeilijker te diagnosticeren dan een directe verbreking, omdat alle indicatoren je vertellen dat 'alles normaal is'.

1. Ontwikkelmachine slaapt / scherm vergrendeld / klep gesloten

Symptomen: de sessie blijft op een bepaald moment volledig stilstaan. Na opnieuw verbinden staat de voortgang nog steeds op het moment van de verbreking, geen stap verder.

Waarom: veel mensen denken 'mijn ontwikkelmachine staat altijd aan', maar systeemslaap, slaap bij het sluiten van de klep en geplande schermvergrendeling zetten het Claude Code-proces op pauze of beëindigen het zelfs. Aan de kijkende kant zie je dan 'plotseling stilstaand'.

Hoe bevestig je: ga terug naar de ontwikkelmachine en kijk of het proces nog bestaat en of er slaapmeldingen in het systeemlogboek staan. Als het proces er nog is maar de tijdstempel vastzit op het moment van de verbreking, dan is het vrijwel zeker dit.

Oplossing: stel het energiebeheerschema van de ontwikkelmachine in op 'niet slapen / niet slapen bij gesloten klep'. Dit is de enige echte remedie — geen enkele externe oplossing kan een machine redden die al slaapt.

2. Netwerkwisseling verbreekt de lange verbinding

Symptomen: de verbinding wordt verbroken op een heel duidelijk moment — een lift ingaan, overschakelen van WiFi naar 4G, of een thuisbreedband die 's nachts opnieuw verbindt.

Waarom: realtime externe synchronisatie werkt via een lange verbinding (WebSocket / SSH). Zodra het IP-adres verandert, is deze verbinding onmiddellijk ongeldig, zonder enige onderhandeling.

Hoe bevestig je: als het moment van verbreking overeenkomt met het moment waarop je van netwerk wisselt, dan is het dit.

Oplossing: dit type is niet te voorkomen; het kan alleen worden opgevangen met automatisch opnieuw verbinden + backoff (1s→2s→5s…, om te voorkomen dat het direct blijft hameren na een verbreking). Bare SSH heeft deze mogelijkheid niet; als het verbroken is, is het verbroken en moet je handmatig opnieuw verbinden. Dit is een harde eis bij het kiezen van een oplossing.

3. Screen-mirroring oplossing: lokaal moet op de voorgrond open blijven

Symptomen: zodra de lokale terminal wordt gesloten of de lokale machine in slaap valt, verbreekt de telefoonkant onmiddellijk de verbinding. Geen geleidelijke timeout, maar een mislukte synchronisatie.

Waarom: de officiële Remote Control van Anthropic projecteert de sessie die lokaal op jouw machine draait naar telefoon/browser. Het uitgangspunt is dat die lokale Claude Code altijd op de voorgrond draait en de lokale machine altijd online is. Zodra de lokale machine uitvalt, heeft de externe kant geen eigen levenscyclus om op te leunen.

Hoe bevestig je: sluit het lokale terminalvenster en kijk of de externe verbinding in dezelfde seconde verbreekt. Zo ja, dan gebruik je een screen-mirroring oplossing.

Oplossing: schakel over op een architectuur met een permanente daemonservice aan de ontwikkelmachine-kant — de kant die de sessie draait wordt een achtergrondservice die automatisch opstart, onafhankelijk van je kijkapparaat. Of het kijkapparaat wordt gesloten, vervangen of verbroken, de service blijft gewoon op de ontwikkelmachine draaien. Dit is het wezenlijke verschil tussen 'screen-mirroring' en 'permanente service'; dat is niet met parameters in te stellen.

4. Halfopen verbinding (half-open): de moeilijkst te ontdekken vorm

Symptomen: toont online, maar berichten krijgen geen reactie, ook geen foutmelding. Het kan enkele minuten vastzitten, of totdat je handmatig opnieuw verbindt.

Waarom: bij een stille netwerkonderbreking (timeout van NAT-tabelitems, tussentoestellen verliezen status, signaal zo zwak dat alleen pakketten verloren gaan maar de verbinding niet verbreekt), kunnen beide TCP-eindpunten denken dat ze nog verbonden zijn, terwijl data er in werkelijkheid niet meer doorkomt. Zonder heartbeat blijven beide partijen deze illusie in stand houden.

Hoe bevestig je: de verbindingsstatus toont normaal, maar verzonden berichten krijgen geen ontvangstbevestiging en geen foutmelding; na handmatig verbreken en opnieuw verbinden is het direct hersteld — dan is het dit.

Oplossing: op de verbinding moet een heartbeat (keepalive ping) draaien: als er binnen de afgesproken tijd geen enkele reactie van de tegenpartij komt, wordt beoordeeld dat dit een halfopen verbinding is en wordt actief verbroken en opnieuw verbonden, in plaats van dom te wachten. Het criterium moet 'geen reactie ontvangen' zijn, niet 'geen foutmelding' — een halfopen verbinding geeft nooit een foutmelding.

5. Opnieuw verbinden komt niet terug in dezelfde sessie / berichten raken kwijt

Symptomen: na een verbreking kun je opnieuw verbinden, maar je komt terug in een lege sessie, of alle berichten die de andere partij tijdens de verbreking stuurde zijn verdwenen.

Waarom: opnieuw verbinden maakt alleen een nieuwe verbinding, zonder die verbinding opnieuw te abonneren op de oorspronkelijke sessie; berichten tijdens de verbreking worden ook niet voor je gebufferd.

Hoe bevestig je: na opnieuw verbinden is het sessie-ID veranderd, of de geschiedenis begint alleen vanaf het moment van opnieuw verbinden.

Oplossing: kies een oplossing die na opnieuw verbinden automatisch terug abonneert op de oorspronkelijke sessie en de geschiedenis van de verbrekingsperiode afspeelt. Alleen opnieuw kunnen verbinden zonder de sessie terug te krijgen, is zinloos.

6. Sessieproces wordt opgeruimd en zonder koud herstel

Symptomen: korte verbrekingen en opnieuw verbinden werken normaal, maar na enkele uren is de sessie verdwenen.

Waarom: een lange tijd inactief sessieproces kan worden opgeruimd, en ook de daemon zelf kan opnieuw zijn gestart (upgrade, crash en opnieuw opgestart). De sessiestatus in het geheugen gaat daarmee verloren.

Hoe bevestig je: het treedt alleen op bij een lange verbreking, niet bij een korte.

Oplossing: er is koud herstel nodig — de sessiestatus wordt op schijf bewaard, zodat zelfs als het proces weg is, de context vanaf de schijf kan worden hersteld. Idealiter stuur je gewoon een bericht en hervat het automatisch, zonder dat je het merkt.

Checklist voor het oplossen (voor elke oplossing te volgen)

Doorloop de volgende stappen in volgorde; elke stap kan onafhankelijk worden weerlegd:

1. Slaapt of is het scherm van de machine die de sessie draait vergrendeld? → Schakel automatische slaap uit en slaap bij gesloten klep uit. (§1)
2. Valt het moment van verbreking samen met het moment waarop je van netwerk wisselt? → Kies een oplossing met automatisch opnieuw verbinden + backoff; vertrouw niet op bare SSH. (§2)
3. Verbreekt de externe verbinding onmiddellijk zodra de lokale terminal wordt gesloten? → Dat is de harde beperking van een screen-mirroring oplossing; je moet overstappen naar een permanente daemonarchitectuur. (§3)
4. Zit je vast in 'toont online maar berichten krijgen geen reactie'? → Halfopen verbinding; alleen heartbeat-detectie kan het automatisch herstellen. (§4)
5. Is de sessie leeg of ontbreken er berichten na opnieuw verbinden? → Er is 'terugkeren naar de oorspronkelijke sessie + geschiedenis afspelen' nodig. (§5)
6. Gaat de sessie alleen verloren bij een lange verbreking? → Er is opslag op schijf + koud herstel nodig. (§6)

Naar een concrete oplossing

Van de zes punten hierboven is alleen punt 1 een instellingsprobleem van je eigen machine; de overige vijf zijn volledig bepaald door de architectuur — ze liggen vast bij de keuze van de oplossing en zijn achteraf niet met parameters te redden.

Een externe oplossing die niet verbreekt moet tegelijkertijd beschikken over: een permanente daemonservice aan de ontwikkelmachine-kant (overeenkomend met de resterende risico's van §1 en §3), automatisch opnieuw verbinden + backoff (§2), heartbeat-detectie (§4), opnieuw verbinden met terugkeer naar de oorspronkelijke sessie + geschiedenis afspelen (§5), en opslag op schijf + koud herstel (§6).

De oplossing PandaNpc + pandapaw is punt voor punt tegen deze zes punten gebouwd: pandapaw registreert zich op de ontwikkelmachine als een permanente daemonservice die automatisch start (geen terminalvenster dat je handmatig open moet houden; na een crash wordt het automatisch herstart); de kijkende kant verbreekt en maakt automatisch opnieuw verbinding met backoff; op de verbinding draait een heartbeat; als er geen reactie komt, wordt het als halfopen beoordeeld en automatisch opnieuw verbonden; na opnieuw verbinden wordt automatisch terug geabonneerd op de oorspronkelijke sessie en wordt de geschiedenis van de verbrekingsperiode afgespeeld; zelfs als het sessieproces wordt opgeruimd, kun je met één bericht de sessie vanaf de schijf koud herstellen en doorgaan.

Zie Claude Code externe toegang voor hoe je het precies installeert en verbindt; zie Mobiel verbinden met Claude Code voor het bekijken van sessies en het goedkeuren van tools op mobiel.

Een bijkomende valkuil: let bij externe sessies op de facturatie

Bij het oplossen van verbindingsproblemen schakelt men makkelijk over op claude -p (headless modus), maar vanaf 15 juni 2026 heeft Anthropic de facturatie aangepast — headless gebruikt niet langer het abonnementsquotum, maar verbruikt een kleine maandelijkse SDK-credit; daarna wordt afgerekend volgens API-tarieven, en bij intensief gebruik is het snel over het budget heen. De interactieve modus (claude REPL) blijft onder het abonnementsquotum vallen. Let er bij het wisselen van oplossing en het oplossen van verbindingsproblemen op dat je niet per ongeluk ook van facturatiemodel wisselt.