Claude Code: feilsøking av eksterne frakoblinger—symptomer, kjennetegn og løsninger for seks måter forbindelsen ryker på

Den eksterne tilkoblingen til Claude Code er brutt. Ikke forhast deg med å koble til igjen – ulike typer brudd gir ulike symptomer, og løsningene er helt forskjellige. Denne artikkelen tar utgangspunkt i «hva du ser» og utleder seks bruddårsaker (maskinen sover, nettverksbytte kutter lange tilkoblinger, skjermspeilingsløsninger krever at maskinen er på, halvdød tilkobling, gjenkobling mister økten, prosessen blir avsluttet). For hver årsak gis det bekreftelseskriterier og tilhørende løsninger, og til slutt en sjekkliste du kan følge i feilsøkingen.

PandaNpcFørst publisert Oppdatert
Claude Code: feilsøking av eksterne frakoblinger—symptomer, kjennetegn og løsninger for seks måter forbindelsen ryker på

Det verste med å kjøre Claude Code eksternt er ikke at du ikke får koblet til—det er at du først får kontakt og så mister den igjen, og hver gang av en annen grunn.

«Frakobling» er egentlig ett ord som skjuler seks helt forskjellige feil. De har hver sine typiske tegn, og løsningene er uavhengige av hverandre—behandler du en varig tilkobling som ble drept av nettverksbytte som om maskinen sov, hjelper det ikke å skru av hvilemodus. Behandler du en halvdød tilkobling som dårlig nett og venter, blir den ikke bra av seg selv.

Denne artikkelen resonnerer bakover fra det du faktisk ser: hver frakoblingstype får symptomer, hvordan du bekrefter at det er denne typen, og den tilsvarende løsningen. Vil du gå rett på sak, hopp til feilsøkingslisten i siste seksjon.

Denne artikkelen handler bare om frakoblingsfeilsøking. Hvordan du setter opp ekstern tilgang, se «Claude Code ekstern tilgang: styr økter hvor som helst selv med den lokale maskinen avslått». Hvordan du bruker den på mobil, se «Koble mobil til Claude Code: se økter og godkjenn verktøy på iOS når som helst».

Sammenlign symptomene først: hvilken type ser du?

En ekstern tilkobling består av to ledd: utviklingsmaskinen som kjører Claude Code ←→ visningsenheten i hånden din. Svikt i enten ledd viser seg som «mistet tilkobling», men symptomene er forskjellige:

Symptom du ser Mest sannsynlig Hopp til
Økten stopper plutselig, og etter gjenkobling ligger fremdriften igjen på samme punkt Utviklingsmaskinen sover / skjermen er låst §1
Mister tilkoblingen idet du går inn i en heis, bytter til 4G eller bytter WiFi Varig tilkobling kuttes §2
Så snart den lokale terminalen lukkes, eller den lokale maskinen sovner, mistes den eksterne tilkoblingen umiddelbart Hard begrensning ved skjermspeiling-løsninger §3
Viser online, men meldinger forsvinner sporløst uten noen feilmelding Halvdød tilkobling §4
Kan koble til igjen, men du får en tom økt / meldingene fra den frakoblede perioden er borte Gjenkoblingen gjenopptok ikke den opprinnelige økten §5
Når du kobler til igjen etter noen timer, er økten borte Prosessen er blitt ryddet opp, og det finnes ingen kald gjenoppretting §6

Den letteste å feilvurdere er den fjerde: den gir ingen feilmelding. Tilkoblingsstatusen er grønn, meldinger sendes uten problemer—men det kommer aldri noe svar. Det er vanskeligere å finne enn et direkte brudd, fordi alle indikatorer sier «alt er normalt».

1. Utviklingsmaskinen sover / skjermen er låst / lokket lukkes

Symptomer: Økten stopper helt opp på et tidspunkt. Etter gjenkobling ligger fremdriften fortsatt på bruddøyeblikket—det har ikke skjedd et eneste steg.

Hvorfor: Mange tror «utviklingsmaskinen min er jo på», men systemhvile, søvn når lokket lukkes og tidsbasert skjermlåsing kan sette Claude Code-prosessen på pause eller drepe den rett ut. På visningssiden ser det bare ut som «den stoppet plutselig».

Slik bekrefter du det: Gå tilbake til utviklingsmaskinen og sjekk om prosessen fortsatt kjører, og om systemloggene har søvnposter. Hvis prosessen fortsatt finnes, men tidsstempelet stopper ved frakoblingstidspunktet, er det nesten sikkert dette.

Løsning: Sett utviklingsmaskinens strømplan til «aldri sov / ikke sovn når lokket lukkes». Dette er den eneste varige løsningen—ingen ekstern løsning kan redde en maskin som allerede sover.

2. Nettverksbytte kutter den varige tilkoblingen

Symptomer: Forbindelsen ryker på et veldig tydelig tidspunkt—du går inn i en heis, WiFi bytter til 4G, eller hjemmebredbåndet kobler opp igjen midt på natten.

Hvorfor: Sanntidssynkronisering over nett bruker én varig tilkobling (WebSocket / SSH). Så snart IP-adressen endres, er den tilkoblingen ugyldig—ingen forhandlingsmulighet.

Slik bekrefter du det: Hvis frakoblingstidspunktet sammenfaller med nettverksbyttet ditt, er det dette.

Løsning: Denne typen kan ikke unngås, kun håndteres med automatisk gjenkobling + backoff (1s→2s→5s…, for å unngå at den hamrer løs med en gang forbindelsen ryker). Bare SSH har ikke denne evnen; er forbindelsen borte, er den borte, og du må koble til manuelt. Dette er et must-krav når du velger løsning.

3. Skjermspeiling-løsninger: den lokale maskinen må kjøre i forgrunnen

Symptomer: Så snart den lokale terminalen lukkes, eller den lokale maskinen sovner, mister mobilen umiddelbart tilkoblingen. Det er ikke en langsom timeout—synkroniseringen dør.

Hvorfor: Anthropics offisielle Remote Control projiserer økten som kjører på din lokale maskin til mobil/nettleser. Forutsetningen er at Claude Code på den lokale maskinen kjører i forgrunnen hele tiden, og at maskinen er online hele tiden. Når den lokale maskinen faller ut, har den eksterne siden ingen egen livssyklus å klamre seg til.

Slik bekrefter du det: Lukk vinduet til den lokale terminalen og se om den eksterne tilkoblingen forsvinner samme sekund. Hvis ja, bruker du en skjermspeiling-løsning.

Løsning: Bytt til en arkitektur med en permanent kjørende daemon-tjeneste på utviklingsmaskinen—den siden som kjører økten, settes opp som en bakgrunnstjeneste som starter ved oppstart og lever uavhengig av visningsenheten din. Selv om visningssiden lukkes, byttes eller mistes, kjører den videre på utviklingsmaskinen som før. Dette er den grunnleggende forskjellen mellom «skjermspeiling» og «permanent tjeneste»—det kan ikke justeres frem med parametere.

4. Halvdød tilkobling (half-open): den vanskeligste å oppdage

Symptomer: Viser online, men meldinger får ikke noe svar, og det kommer ingen feilmelding. Det kan henge i noen minutter, eller helt til du manuelt kobler til igjen.

Hvorfor: Når nettverket brytes stille (NAT-tabelloppføringer utløper, mellomliggende enheter mister tilstand, signalet er så svakt at pakker bare droppes uten at forbindelsen ryker), kan begge TCP-endepunktene tro at de fortsatt er tilkoblet, selv om data aldri kommer gjennom. Uten heartbeat vil begge sider opprettholde denne illusjonen.

Slik bekrefter du det: Tilkoblingsstatusen virker normal, men sendte meldinger får verken leveringsbekreftelse eller feilmelding. Alt fungerer igjen med en gang etter manuell gjenkobling—da er det dette.

Løsning: Tilkoblingen må ha heartbeat (keepalive ping): får du ikke noe svar fra motparten innen avtalt tid, erklærer du tilkoblingen halvdød og kobler aktivt fra og til igjen, i stedet for å vente passivt. Kriteriet må være «ingen svar», ikke «ingen feilmelding»—en halvdød tilkobling gir aldri feilmelding.

5. Gjenkobling som ikke gjenopptar den opprinnelige økten / taper meldinger

Symptomer: Etter et brudd kan du koble til igjen, men enten får du en tom økt, eller alle meldinger som kom i frakoblingsperioden er borte.

Hvorfor: Gjenkobling oppretter bare en ny tilkobling; den abonnerer ikke tilbake på den opprinnelige økten. Meldingene fra frakoblingsperioden er heller ikke bufret for deg.

Slik bekrefter du det: Etter gjenkobling har økten en annen ID, eller historikken starter bare fra gjenkoblingstidspunktet.

Løsning: Velg en løsning som automatisk abonnerer tilbake på den opprinnelige økten etter gjenkobling og spiller av historikken fra frakoblingsperioden. Å bare kunne koble til igjen uten å gjenoppta økten er bortkastet.

6. Øktprosessen blir ryddet opp, uten kald gjenoppretting

Symptomer: Korte frakoblinger og gjenkoblinger fungerer fint, men kommer du tilbake etter noen timer, er økten borte.

Hvorfor: En øktprosess som har vært inaktiv lenge, kan bli ryddet opp, og selve daemon-prosessen kan også ha blitt startet på nytt (oppgradering, krasj og automatisk restart). Øktstatusen i minnet forsvinner dermed.

Slik bekrefter du det: Problemet oppstår bare ved lange frakoblinger, ikke korte.

Løsning: Du trenger kald gjenoppretting (cold recovery)—økten skrives til disk, så selv om prosessen er borte, kan konteksten gjenopprettes fra disken. Ideelt sett sender du bare en melding, og den gjenopptas automatisk, uten at du merker noe.

Feilsøkingsliste (følg den uansett hvilken løsning du bruker)

Gå gjennom i rekkefølge. Hvert trinn kan tilbakevises uavhengig:

  1. Sover maskinen som kjører økten, eller er skjermen låst? → Slå av automatisk hvile, ikke sovn ved lukket lokk. (§1)
  2. Sammenfaller frakoblingstidspunktet med nettverksbyttet ditt? → Du trenger en løsning med automatisk gjenkobling + backoff, ikke bare SSH. (§2)
  3. Forsvinner den eksterne tilkoblingen med en gang den lokale terminalen lukkes? → Det er en hard begrensning ved skjermspeiling-løsninger; bytt til en permanent daemon-arkitektur. (§3)
  4. Står det fast på «viser online, men meldinger får ikke svar»? → Halvdød tilkobling; bare heartbeat-deteksjon kan redde den automatisk. (§4)
  5. Er økten tom / mangler meldinger etter gjenkobling? → Du trenger «gjenoppta opprinnelig økt + historisk avspilling». (§5)
  6. Forsvinner økten bare etter lange frakoblinger? → Du trenger lagring til disk + kald gjenoppretting. (§6)

Når du velger konkret løsning

Av de seks punktene ovenfor er bare punkt 1 et innstillingsproblem på din egen maskin. De andre fem er avgjort av arkitekturen—de er fastlåst når du velger løsning, og kan ikke reddes med parameterjustering etter at problemet har oppstått.

En ekstern løsning som ikke mister forbindelsen, må ha alt dette samtidig: en permanent daemon-prosess på utviklingsmaskinen (dekker gjenværende risiko i §1 og §3), automatisk gjenkobling + backoff (§2), heartbeat-deteksjon (§4), gjenkobling til opprinnelig økt + historisk avspilling (§5), og kald gjenoppretting fra disk (§6).

PandaNpc + pandapaw-oppsettet er bygget punkt for punkt mot disse seks kravene: pandapaw registreres på utviklingsmaskinen som en permanent daemon-tjeneste som starter ved oppstart (ikke et terminalvindu du må holde åpent manuelt; hvis den krasjer, startes den automatisk på nytt). Ved frakobling kobler visningssiden automatisk til igjen med backoff. Tilkoblingen kjører heartbeat; hvis svar uteblir, erklæres den halvdød, og den kobler aktivt til igjen. Etter gjenkobling abonnerer den automatisk tilbake på den opprinnelige økten og spiller av historikken fra frakoblingsperioden. Selv om øktprosessen blir ryddet opp, kan du sende én melding og få kald gjenoppretting fra disk for å fortsette.

Se «Claude Code ekstern tilgang» for hvordan du installerer og kobler til. Se «Koble mobil til Claude Code» for øktvisning og verktøygodkjenning på mobil.

En ekstra felle: pass på faktureringen når du kjører eksternt

Når du feilsøker frakoblinger, er det lett å bytte til claude -p (headless-modus), men fra 15. juni 2026 endret Anthropic faktureringen—headless går ikke lenger på abonnementskvoten, men trekker på et lite månedlig SDK-kredittbeløp. Når kreditten er brukt opp, faktureres det etter API, og ved tung bruk er det lett å sprenge budsjettet. Interaktiv modus (claude REPL) går fortsatt på abonnementskvoten. Når du bytter løsning for å feilsøke frakoblinger, pass på at du ikke også bytter faktureringsmodus ved en feiltakelse.