Claude Code Felsökning av fjärravbrott: symptom, kriterier och lösningar för sex sätt att kopplas bort

Att köra Claude Code på distans är jobbigast inte när man inte kan ansluta, utan när anslutningen väl är uppe så bryts den, och varje gång avbryts den av en annan anledning.

Ordet »avbrott« täcker egentligen sex helt olika typer av fel. Deras symptom är karakteristiska för varje typ, och lösningarna är oberoende av varandra – att behandla en långvarig anslutning som brutits på grund av nätverksbyte som om maskinen sov, hjälper inte ens om du stänger av viloläget; att vänta på att en halvdöd anslutning ska bli bättre som om det vore dåligt nätverk, kommer inte att lösa sig av sig självt ens till morgonen.

Den här artikeln härleder orsaken utifrån vad du faktiskt observerar: för varje typ av avbrott ges symptom, hur du bekräftar att det är just den, och motsvarande lösning. Vill du sätta igång direkt, hoppa till felsökningslistan i sista avsnittet.

Det här avsnittet handlar bara om felsökning av avbrott. Hur du sätter upp fjärråtkomst finns i »Claude Code fjärråtkomst: stäng av den lokala datorn och styr sessionen var du än är«, och hur du använder mobilen finns i »Mobilen ansluter till Claude Code: visa sessioner och godkänn verktyg när som helst på iOS«.

Börja med symptomen: vilken typ ser du?

En fjärranslutning består av två delar: utvecklingsmaskinen som kör Claude Code ←→ enheten du tittar på i handen. Om någon av de två delarna har problem visar det sig som »avbrott«, men symptomen skiljer sig åt:

Vad du observerar	Troligen	Hoppa till
Sessionen slutar plötsligt röra sig, och när du återansluter ser du att förloppet stannat vid det ögonblicket	Utvecklingsmaskinen sover / skärmen låst	§1
Avbrott i samma ögonblick som du går in i en hiss, byter till 4G, eller byter WiFi	Långvarig anslutning kapad	§2
Så fort den lokala terminalen stängs, eller den lokala maskinen somnar, bryts fjärranslutningen omedelbart	Hård begränsning hos skärmdelningslösningar	§3
Visar online, men meddelanden försvinner utan något felmeddelande	Halvdöd anslutning	§4
Kan återansluta, men du kommer tillbaka till en tom session / meddelanden under avbrottet är borta	Återanslutningen kopplade inte tillbaka till originalsessionen	§5
Efter några timmar är sessionen borta	Processen har återvunnits, och ingen kall återställning finns	§6

Den lättaste att feltolka är den fjärde: den ger inga felmeddelanden. Anslutningsstatusen är grön, meddelanden skickas iväg, men det kommer aldrig något svar – svårare att felsöka än ett direkt avbrott, eftersom alla indikatorer säger »allt är normalt«.

1. Utvecklingsmaskinen sover / skärmen låst / locket stängt

Symptom: Sessionen stannar helt vid en viss tidpunkt. När du återansluter är förloppet fortfarande kvar vid avbrottsögonblicket, inte ett steg längre.

Varför: Många tror »min utvecklingsmaskin är alltid på«, men systemviloläge, sömn vid stängt lock och schemalagd skärmlåsning kommer att pausa eller direkt döda Claude Code-processen. På visningssidan ser det ut som »stannade plötsligt«.

Så bekräftar du: Gå tillbaka till utvecklingsmaskinen och kontrollera om processen fortfarande finns och om systemloggen har några sömnposter. Om processen fortfarande finns men tidsstämpeln står stilla vid avbrottstidpunkten, är det i princip detta.

Lösning: Ställ in utvecklingsmaskinens energischema på »sleep aldrig / sov inte när locket stängs«. Det är det enda som åtgärdar grundorsaken – ingen fjärrlösning kan rädda en maskin som redan somnat.

2. Nätverksbyte kapar den långvariga anslutningen

Symptom: Avbrottet sker i ett mycket tydligt ögonblick – du går in i en hiss, WiFi byter till 4G, eller hembredbandet ringer upp igen mitt i natten.

Varför: Fjärrsynkronisering i realtid bygger på en långvarig anslutning (WebSocket / SSH). När IP-adressen ändras blir anslutningen omedelbart ogiltig, utan några förhandlingar.

Så bekräftar du: Om avbrottstidpunkten sammanfaller med när du bytte nätverk, är det detta.

Lösning: Den här typen går inte att undvika, utan du måste fånga upp det med automatisk återanslutning + backoff (1s→2s→5s…, för att undvika att hamra så fort det bryts). Ren SSH saknar den här förmågan; när det är avbrutet, är det avbrutet, och du måste skriva manuellt. Detta är ett hårt krav när du väljer lösning.

3. Skärmdelningslösningar: den lokala maskinen måste vara öppen i förgrunden

Symptom: Så fort den lokala terminalen stängs, eller den lokala maskinen somnar, bryts anslutningen på telefonen omedelbart. Det är inte en långsam timeout, utan synkroniseringen upphör.

Varför: Anthropics officiella Remote Control projicerar sessionen som körs på din lokala maskin till telefonen/webbläsaren. Förutsättningen är att Claude Code på den lokala maskinen alltid körs i förgrunden och att maskinen alltid är online. Så fort den lokala maskinen försvinner har fjärrsidan ingen oberoende livscykel att hålla sig till.

Så bekräftar du: Stäng det lokala terminalfönstret och se om fjärranslutningen bryts i samma sekund. Om så är fallet använder du en skärmdelningslösning.

Lösning: Byt till en arkitektur med en ständigt aktiv daemon-tjänst på utvecklingsmaskinen – den sida som kör sessionen görs till en bakgrundstjänst som startar automatiskt vid uppstart och lever oberoende av din visningsenhet. Oavsett om visningssidan stängs, byts ut eller kopplas bort, fortsätter den att köra på utvecklingsmaskinen. Detta är den grundläggande skillnaden mellan »skärmdelning« och »ständigt aktiv tjänst«, och den kan inte justeras fram med parametrar.

4. Halvdöd anslutning (half-open): den svåraste att upptäcka

Symptom: Visar online, men meddelanden får inget svar, och inga felmeddelanden. Det kan fastna i några minuter, eller ända tills du manuellt återansluter.

Varför: När nätverket tyst avbryts (NAT-tabellposter timeout, mellanliggande enheter förlorar status, signal så svag att paket tappas men länken inte bryts), kan båda TCP-ändarna tro att de fortfarande är anslutna, medan data faktiskt aldrig kommer fram. Utan heartbeat upprätthåller båda sidor denna illusion.

Så bekräftar du: Anslutningsstatusen visar normal, men skickade meddelanden varken får leveranskvitto eller felmeddelande; efter att du manuellt kopplat bort och återanslutit återställs det omedelbart – då är det detta.

Lösning: Anslutningen måste köra heartbeat (keepalive ping): om inget svar från motparten kommer inom den överenskomna tiden, bedöm att det är en halvdöd anslutning och koppla aktivt bort och återanslut, i stället för att vänta passivt. Kriteriet måste vara »inget svar mottaget«, inte »inget felmeddelande« – en halvdöd anslutning ger aldrig felmeddelanden.

5. Återanslutningen kopplar inte tillbaka till originalsessionen / tappar meddelanden

Symptom: Efter avbrottet går det att återansluta, men antingen är sessionen tom, eller så är alla meddelanden som skickades under avbrottet borta.

Varför: Återanslutningen skapar bara en ny anslutning, utan att prenumerera tillbaka den på originalsessionen; meddelanden under avbrottet har inte heller cachats åt dig.

Så bekräftar du: Efter återanslutning har sessionens ID ändrats, eller historiken börjar först från återanslutningsögonblicket.

Lösning: Välj en lösning som efter återanslutning automatiskt prenumererar tillbaka på originalsessionen och spelar upp historiken från avbrottet. Att bara kunna återansluta men inte koppla tillbaka är lika värdelöst som att inte ansluta alls.

6. Sessionsprocessen återvinns, och ingen kall återställning finns

Symptom: Korta avbrott och återanslutningar fungerar normalt, men när du kommer tillbaka efter några timmar är sessionen borta.

Varför: En sessionsprocess som varit inaktiv länge kan återvinnas, och själva daemonen kan ha startats om (uppgradering, start efter krasch). Sessionsstatusen i minnet försvinner därmed.

Så bekräftar du: Problemet återkommer bara vid långa avbrott, inte vid korta.

Lösning: Du behöver kall återställning – sessionsstatusen sparas på disk, så att kontexten kan återställas från disken även om processen är borta. I bästa fall återställs den automatiskt och fortsätter när du skickar ett meddelande, utan att du märker det.

Felsökningslista (kan följas oavsett lösning)

Gå igenom i ordning, varje steg kan oberoende motbevisas:

1. Sover / är skärmen låst på maskinen som kör sessionen? → Stäng av automatisk viloläge och sömn vid stängt lock. (§1)
2. Sammanfaller avbrottstidpunkten med när du bytte nätverk? → Du behöver en lösning med automatisk återanslutning + backoff, lita inte på ren SSH. (§2)
3. Bryts fjärranslutningen direkt när den lokala terminalen stängs? → Det är en hård begränsning hos skärmdelningslösningar, du måste byta till en ständigt aktiv daemon-arkitektur. (§3)
4. Fastnat i »visar online men meddelanden får inget svar«? → Halvdöd anslutning, bara heartbeat-detektering kan rädda det automatiskt. (§4)
5. Sessionen är tom / meddelanden saknas efter återanslutning? → Du behöver »koppla tillbaka till originalsessionen + historikuppspelning«. (§5)
6. Förlorar du sessionen bara efter långa avbrott? → Du behöver spara till disk + kall återställning. (§6)

När vi kommer till konkreta lösningar

Av de sex punkterna ovan är bara punkt 1 ett problem med inställningarna på din egen maskin; de övriga fem är helt bestämda av arkitekturen – de är låsta redan vid valet av lösning, och när problemet väl uppstår kan du inte rädda det genom att justera parametrar.

En fjärrlösning som inte bryts måste samtidigt ha: en ständigt aktiv daemon-process på utvecklingsmaskinen (motsvarar resterande risk i §1 och §3), automatisk återanslutning + backoff (§2), heartbeat-detektering (§4), återanslutning tillbaka till originalsessionen + historikuppspelning (§5), samt spara till disk för kall återställning (§6).

PandaNpc + pandapaw är utformat för att punkt för punkt motsvara dessa sex: pandapaw registreras på utvecklingsmaskinen som en ständigt aktiv daemon-process som startar automatiskt vid uppstart (inte ett terminalfönster du måste hålla öppet manuellt; startas automatiskt igen efter en krasch); visningssidan återansluter automatiskt med backoff vid avbrott; anslutningen kör heartbeat, och om inget svar kommer bedöms den som halvdöd och återansluter aktivt; efter återanslutning prenumererar den automatiskt tillbaka på originalsessionen och spelar upp historiken från avbrottet; även om sessionsprocessen återvinns kan ett enda meddelande återställa den från disk och fortsätta.

Hur du installerar och ansluter i praktiken finns i »Claude Code fjärråtkomst«; sessionsvisning och verktygsgodkännande på mobilen finns i »Mobilen ansluter till Claude Code«.

En extra fallgrop: se upp med debitering när du kör på distans

Vid felsökning av avbrott är det lätt att byta till claude -p (headless-läge), men från och med 15 juni 2026 har Anthropic ändrat debiteringen – headless går inte längre via prenumerationskvoten, utan förbrukar en liten månatlig SDK-kredit, och när den är slut debiteras det enligt API-användning, så vid tung användning blir det lätt att överskrida. Interaktivt läge (claude REPL) går fortfarande via prenumerationskvoten. När du byter lösning för att felsöka avbrott, se till att du inte också byter debiteringsmodell av misstag.