GitHub Copilot Lokal Sandbox: 12 Trin, 45 Min

Den 7. oktober 2026 satte GitHub et punktum for en af de mest omdiskuterede sikkerhedshuller i agent-baseret kodning: at en AI-agent kan røre ved hele din maskine, mens den løser en opgave. Lokal sandboxing til GitHub Copilot blev gjort generelt tilgængelig den dag, og funktionen virker nu i GitHub Copilot CLI, GitHub Copilot-appen og VS Code-sessioner, der bruger Agent Host. I denne guide, der hører under vores dækning af AI-kodeværktøjer, viser vi dig, hvordan du sætter det op fra bunden, trin for trin, med rigtige kommandoer og et komplet eksempelprojekt du kan teste med det samme.

Sandboxing er ikke kosmetisk. Når Copilots agent kører shell-kommandoer, redigerer filer eller kalder MCP-servere på dine vegne, har den som udgangspunkt adgang til alt, hvad din bruger har adgang til, inklusive SSH-nøgler, Git-credentials og dit hjemmekatalog. Med lokal sandboxing kan du og din organisation begrænse præcis det, uden at skifte værktøj eller flytte arbejdet til skyen. Vi gennemgår opsætning i CLI, VS Code og appen, politikker for filsystem, netværk og credentials, virksomhedsstyring via Intune, og vi bygger et lille Node.js-projekt, så du kan se sandboxen i aktion.

Guiden er skrevet, så du kan følge den fra en tom terminal til en fuldt konfigureret, beskyttet opsætning uden at skulle slå noget op undervejs. Vi starter med begreberne, fordi sandbox-terminologien hos GitHub er blevet brugt om flere forskellige ting i løbet af 2026, og en del af forvirringen i danske udviklermiljøer stammer netop fra, at “sandkasse” både dækker et modeltestprogram og den sikkerhedsfunktion, vi dækker her.

Hvad er lokal sandboxing i GitHub Copilot?

Lokal sandboxing er en sikkerhedsgrænse, der ligger mellem Copilots agent og dit operativsystem. Når funktionen er slået til, kører kommandoer og værktøjskald, som agenten selv starter, med begrænset adgang til filsystem, netværk, credentials og andre systemfunktioner, baseret på en politik du eller din organisation definerer. GitHub beskriver det i sin changelog fra 7. oktober 2026 som en måde at give udviklere en sikker udførelsesgrænse for agentiske arbejdsgange på deres egne maskiner.

Teknologien bag kaldes Microsoft eXecution Container, forkortet MXC. MXC oversætter én fælles sandbox-politik til indbyggede styresystemkontroller på tværs af Windows, macOS og Linux, så du får samme adfærd uanset platform. Det betyder i praksis, at en politik, du sætter op på din Mac, opfører sig på samme måde, hvis en kollega bruger den på Windows eller Linux.

Vigtigt: modelvalg og værktøjsisolering er to forskellige ting. Uanset om du kører Claude, GPT-6.1 Sol eller en af Copilots egne modeller, gælder sandbox-politikken for selve værktøjsudførelsen, ikke for hvilken AI-model der tænker opgaven igennem. Det løser GitHub ved at adskille “hvad agenten foreslår” fra “hvad agenten rent faktisk må gøre på din maskine”. Den adskillelse er afgørende, fordi den betyder, at du ikke behøver stole fuldstændig på en bestemt model for at få en fornuftig sikkerhedsbund. Selv hvis en model en dag skulle foreslå noget, den ikke burde, er det stadig sandbox-politikken, der afgør, om kommandoen rent faktisk kan udføres mod dit filsystem og netværk.

Sandbox-funktionen vs. “Sandkasse”-programmet: undgå forvirring

Hvis du har læst om GitHub Copilots “Sandkasse”-program med nye modeller som Hydra og Fusion, er det let at tro, det er samme funktion. Det er det ikke. Copilot Sandbox er et testprogram, hvor GitHub lader brugere prøve eksperimentelle AI-modeller, før de bliver officielle. Lokal sandboxing, som vi dækker her, er derimod en sikkerhedsfunktion, der isolerer agentens adgang til din maskine, uanset hvilken model du har valgt.

De to funktioner kan sagtens bruges samtidig. Du kan køre en model fra model-sandkassen, mens værktøjsudførelsen stadig er beskyttet af den lokale sikkerheds-sandbox. Hold de to begreber adskilt, når du læser dokumentation eller spørger kolleger, ellers ender du med at lede efter de forkerte indstillinger.

Et praktisk kneb, hvis du er i tvivl om, hvilken funktion en kollega mener: spørg om det handler om, hvilken model der svarer i chatten, eller om det handler om, hvad agenten må røre ved på maskinen. Det første hører til model-sandkassen, det andet hører til den sikkerhedsfunktion, resten af denne guide handler om.

Forudsætninger: det skal du bruge, før du starter

Før du går i gang, skal du sikre dig, at din opsætning matcher kravene. Lokal sandboxing er inkluderet i alle Copilot-planer uden ekstra pris, men enkelte dele, særligt central styring, kræver Business eller Enterprise. Tabellen herunder opsummerer, hvad du skal bruge alt efter hvilken Copilot-overflade du vil beskytte.

Komponent	Krav	Bemærkning
GitHub Copilot-plan	Free, Pro, Pro+, Business eller Enterprise	Sandboxing koster ikke ekstra, uanset plan
Copilot CLI	Pakken @github/copilot via npm	Kræver Node.js 22 eller nyere
VS Code	Nyeste udgave med Agent Host-sessioner	Sandboxing virker kun i sessioner, der bruger Agent Host
GitHub Copilot-appen	Nyeste udgave, macOS/Windows/Linux	Sandboxing er slået fra som standard pr. projekt
Operativsystem	Windows, macOS eller Linux	MXC dækker alle tre uden Docker
Organisationsadgang	Kun for Business/Enterprise	Krævet for centrale politikker via Intune eller anden MDM

Bemærk at lokal sandboxing ikke kræver Docker eller en separat virtuel maskine. MXC arbejder direkte med styresystemets egne isoleringsmekanismer, hvilket gør opstartstiden kort sammenlignet med klassiske container-løsninger. Hvis du allerede bruger brugerdefinerede instruktioner til Copilot eller har sat automatiseringer op, virker sandboxing som et ekstra lag oven på det, du allerede har konfigureret.

Node.js-kravet er værd at dvæle lidt ved, fordi det ofte er der, opsætningen går galt for folk, der ikke har opdateret deres udviklingsmiljø for nylig. Mange teams sidder stadig med Node.js 18 eller 20 installeret som standard, fordi det var den anbefalede LTS-version for et par år siden. Copilot CLI kræver Node.js 22 eller nyere, så kør node –version, før du installerer noget som helst, og opgradér via din foretrukne versionshåndtering, hvis du er under kravet. Spring du det trin over, ender installationen typisk med en kryptisk npm-fejl, der ikke umiddelbart nævner Node-versionen som årsagen.

Sandbox vs. containere og virtuelle maskiner: hvad er forskellen?

Mange udviklere kender allerede isolation fra Docker-containere eller virtuelle maskiner, så det er naturligt at spørge, hvorfor GitHub ikke bare genbruger den tilgang. Forskellen ligger i, hvad der isoleres, og hvor meget det koster at starte. En Docker-container eller en VM isolerer typisk et helt kørende miljø, med sit eget filsystem, sine egne processer og ofte sit eget netværksstack, og kræver en separat runtime, du selv skal installere og vedligeholde.

MXC-baseret sandboxing går en anden vej. I stedet for at pakke hele miljøet ind, oversætter den en politik til kontroller, som dit eksisterende styresystem allerede understøtter, og den gælder kun for de kommandoer, agenten selv starter, ikke for hele din session. Det betyder, at opstartstiden er markant kortere end at spinne en container op, og at du ikke behøver Docker Desktop eller en hypervisor installeret for at få beskyttelsen. Til gengæld giver det ikke samme grad af fuldstændig isolation, som en komplet VM gør. Hvis du har brug for et helt isoleret, engangs-miljø, for eksempel til at afprøve ukendt tredjepartskode, er GitHubs cloud-sandbox, som vi vender tilbage til senere i denne guide, et bedre match end den lokale variant.

Trin 1-3: installer og opdater GitHub Copilot CLI

Det første trin er at sikre, at du kører en version af Copilot CLI, der understøtter sandboxing. Hvis du aldrig har installeret CLI’en, bruger du npm-pakken @github/copilot. Har du den allerede, er det nok at opdatere til seneste version.

# Trin 1: Installer GitHub Copilot CLI (kræver Node.js 22+)
npm install -g @github/copilot

# Trin 2: Bekræft installationen
copilot --version

# Trin 3: Log ind med din GitHub-konto
copilot auth login

Hvis din organisation blokerer npm-scripts som standard, giver GitHub et alternativ, der eksplicit tillader installationsscriptet at køre. Du kan også bruge et shell-baseret installationsscript, hvis du foretrækker ikke at gå via npm direkte.

# Alternativ, hvis npm-scripts er slået fra
npm_config_ignore_scripts=false npm install -g @github/copilot

# Alternativ installationsmetode uden npm
curl -fsSL https://gh.io/copilot-install | bash

Når copilot --version svarer med et versionsnummer, er CLI’en klar. Hvis din organisation er på Business eller Enterprise, skal en administrator desuden have aktiveret Copilot CLI-politikken i organisationens indstillinger, ellers kan du logge ind, men ikke starte sessioner.

Trin 4-6: aktiver lokal sandboxing i en CLI-session

Når CLI’en er installeret, starter du en almindelig Copilot-session og slår sandboxing til indefra. Kommandoen hedder /sandbox enable, og den virker direkte i din interaktive session uden genstart.

# Trin 4: Start en interaktiv Copilot CLI-session i dit projekt
cd ~/projekter/mit-api-projekt
copilot

# Trin 5: Slå sandboxing til for den aktive session
/sandbox enable

# Trin 6: Bed agenten om at udføre en opgave som normalt
Opret en fil kaldet notes.txt med dagens dato

Efter trin 5 kører alle shell-kommandoer, agenten selv igangsætter for den session, med begrænset adgang til filsystem, netværk og systemfunktioner. Bemærk at dette kun dækker kommandoer, Copilot selv foreslår og kører, ikke kommandoer du manuelt skriver i samme terminal uden om agenten.

Et vigtigt designvalg fra GitHub er, at sandboxen fejler lukket. Hvis dit styresystem ikke kan håndhæve den politik, du har bedt om, nægter den sandboxede shell at køre, i stedet for stiltiende at falde tilbage til ubeskyttet udførelse. Det er en markant anderledes tilgang end mange tidligere sikkerhedsfunktioner, der typisk fejler åbent, og det er værd at huske, når du fejlfinder senere i denne guide.

Trin 7-9: sandboxing i VS Code med Agent Host

I VS Code hænger sandboxing sammen med Agent Host-sessioner, den nyere arkitektur Copilot bruger til agent-tilstand. Du behøver ikke en separat udvidelse ud over den almindelige GitHub Copilot-udvidelse, men du skal sikre, at din session rent faktisk kører via Agent Host, før sandbox-indstillingerne har effekt.

Trin 7 er at åbne Copilot Chat i agent-tilstand i VS Code og starte en ny session i dit projekt. Trin 8 er at tjekke, at sessionen kører som en Agent Host-session, hvilket typisk fremgår af sessionsoplysningerne i chat-panelet. Trin 9 er at anvende de samme sandbox-politikker, du kender fra CLI’en eller appen, da VS Code deler den underliggende MXC-motor med de to andre overflader. Hvis du allerede har sat Copilot op til kodegennemgang, påvirker sandboxing ikke selve review-funktionen, da den udelukkende begrænser værktøjsudførelse, ikke chat eller forslag.

Når en Agent Host-session er sandboxed, viser VS Code typisk en tydelig markering i sessionsvinduet, så du kan se, om den aktuelle session kører beskyttet eller ej, inden du beder agenten om at udføre opgaver, der rører filsystemet.

Trin 10-12: konfigurer sandboxing i GitHub Copilot-appen

I den stationære Copilot-app er sandboxing, som GitHub beskrev, da funktionen kom i preview den 23. september 2026, slået fra som standard, og du konfigurerer den pr. projekt frem for globalt. Det giver mening, hvis du arbejder på flere projekter med forskellige tillidsniveauer, for eksempel et internt værktøj versus et open source-bidrag.

Trin 10 er at åbne appens indstillinger og vælge det projekt, du vil beskytte. Trin 11 er at slå “Sandbox new sessions” til under sektionen Sandbox. Denne indstilling gælder kun for nye sessioner i projektet, ikke sessioner der allerede kører, så du skal eventuelt genstarte en igangværende session for at få den omfattet. Trin 12 er at justere de tre politikkategorier, appen tilbyder: filsystem, netværk og credentials.

# Slå sandboxing til for en allerede aktiv session uden at ændre projektets standard
/sandbox on

# Slå sandboxing fra igen for den aktive session
/sandbox off

GitHub Copilot-appen og Copilot CLI konfigureres hver for sig. Det er med vilje, da appen typisk bruges til længerevarende, projektbundne sessioner, mens CLI-sessioner ofte er korte og ad hoc. Hvis du vil have samme beskyttelse begge steder, skal du altså sætte politikkerne op to gange, én gang pr. overflade.

Filsystem-politikker: styr hvad agenten må læse og skrive

Filsystem-politikken er ofte den vigtigste, fordi den afgør, om en fejlfortolket instruktion fra agenten kan slette eller overskrive filer uden for dit projekt. Copilot-appen deler politikken op i tre lister: ekstra mapper med læse/skriv-adgang, ekstra mapper med kun læseadgang, og mapper der er direkte nægtet.

Politiktype	Hvad den styrer	Typisk brug
Ekstra læs/skriv	Mapper agenten må ændre ud over selve projektet	Delte biblioteker, monorepo-undermapper
Ekstra kun læsning	Mapper agenten må se, men ikke ændre	Konfigurationsfiler, delte typer/skemaer
Nægtet	Mapper agenten slet ikke må tilgå	Hjemmekatalog, SSH-nøgler, andre projekter
Netværk, internet	Udgående adgang til det offentlige internet	Pakkehentning, API-kald under udvikling
Netværk, lokalt	Adgang til tjenester på dit lokale netværk	Lokale databaser, interne test-servere
Credentials, Git	Git-legitimationsoplysninger til HTTPS-operationer	Commit, push, pull mod eksterne repos
Credentials, GitHub CLI	Adgang til din gh-godkendelse	Oprettelse af PR’er, issues via CLI

En fornuftig startpolitik for de fleste projekter er: tillad læs/skriv kun i selve projektmappen, giv kun læseadgang til eventuelle delte konfigurationsmapper, og nægt eksplicit adgang til dit hjemmekatalogs rod samt mapper med SSH-nøgler. Det lyder restriktivt, men de fleste agent-opgaver, oprettelse af filer, redigering af kode, kørsel af tests, kræver ikke mere end det.

Netværk og credentials: luk for internettet og dine nøgler

Netværkspolitikken afgør, om agentens kommandoer kan nå det offentlige internet og dit lokale netværk. Det er særligt relevant, hvis du bruger Copilot til at installere afhængigheder automatisk, for eksempel via npm install eller pip install, da det kræver udgående internetadgang for at virke.

Credential-politikken er mere snæver, men mindst lige så vigtig. Den styrer specifikt, om agentens kommandoer må bruge dine Git-legitimationsoplysninger til autentificerede HTTPS-operationer, og om de må bruge din GitHub CLI-godkendelse. Uden adgang her kan agenten stadig læse og redigere lokale filer, men den kan ikke committe til eller pushe til et eksternt repository på dine vegne, medmindre du eksplicit tillader det.

En praktisk tommelfingerregel: slå netværksadgang fra, når du beder agenten om rene refaktoreringsopgaver, der ikke kræver nye pakker, og slå credential-adgang fra, indtil du selv har set og godkendt de ændringer, agenten foreslår. Det tvinger dig til at gennemgå diffs manuelt, før noget ender i et delt repository, hvilket minder om den samme forsigtighed, vi anbefaler i vores gennemgang af Copilots agent-tilladelser.

Et konkret eksempel: forestil dig, at du beder agenten om at opdatere afhængigheder i et projekt, rydde op i gammel kode og committe resultatet i én arbejdsgang. Uden en stram politik ville agenten kunne nå ud på internettet, hente nye pakkeversioner, og pushe direkte til din fjern-repo, alt sammen uden du så en eneste diff undervejs. Med netværksadgang begrænset til pakkeregistre og credential-adgang slået fra, bliver de samme trin i stedet brudt op: agenten foreslår opdateringerne, du godkender dem, og først derefter får den lov til at committe. Den ekstra friktion er lille, men den er præcis der, hvor en fejl bliver fanget, før den rammer produktion.

Virksomhedsstyring: Intune, MDM og enterprise-politikker

For Business- og Enterprise-kunder er det ikke nok, at den enkelte udvikler kan slå sandboxing til. GitHub giver administratorer mulighed for centralt at kræve sandboxing og håndhæve politikker, som udviklere ikke selv kan svække. Det fungerer gennem enterprise-managed settings, der kan distribueres via Microsoft Intune eller andre MDM-platforme (mobile device management).

For JetBrains-brugere kom en tilsvarende, organisationsstyret sandbox-funktion i offentlig preview den 8. september 2026. Her kan administratorer centralt konfigurere sandbox-aktivering, adgang til filsystem og netværk, proxy-indstillinger, adgang til udviklerværktøjer og endda adgang til macOS Keychain. Når en indstilling er organisationsstyret, låser Copilot den tilsvarende kontrol i selve IDE’en og markerer tydeligt, at den styres centralt, så den enkelte udvikler ikke ved et uheld kan omgå den.

Praktisk betyder det, at en sikkerhedsansvarlig kan rulle en fælles politik ud til hele udviklingsafdelingen på én gang, uden at afhænge af, at hver enkelt udvikler husker at slå sandboxing til manuelt. Det er samme logik, som ligger bag mange af de organisationsstyrede instruktioner, GitHub har udrullet til Copilot gennem 2026.

For en it-sikkerhedsafdeling er det centrale punkt, at håndhævelsen ikke afhænger af god vilje fra den enkelte udvikler. En politik, der kun er en anbefaling i et internt wiki-dokument, bliver før eller siden ignoreret under tidspres. En politik, der er låst via enterprise-managed settings, kan simpelthen ikke slås fra af en travl udvikler, der lige skal nå en deadline. Det er den samme forskel, der typisk ligger mellem en retningslinje og en reel kontrol i enhver sikkerhedsmodel, og det er derfor, GitHub har valgt at give administratorer mulighed for at låse netop disse indstillinger frem for blot at anbefale dem.

Cloud-sandbox som supplement: copilot –cloud

Ud over lokal sandboxing tilbyder GitHub også en cloud-sandbox, som blev annonceret i offentlig preview samme dag som den lokale variant, den 2. juni 2026. Hvor lokal sandboxing isolerer agenten på din egen maskine, starter cloud-sandboxen et fuldt isoleret, midlertidigt Linux-miljø hostet af GitHub.

# Start en session i en fuldt isoleret cloud-sandbox i stedet for lokalt
copilot --cloud

Når du bruger copilot –cloud, arver sessionen automatisk de cloud-agent-politikker, din organisation allerede har sat op, så sikkerhedskontrollerne gælder fra dag ét uden ekstra konfiguration. Cloud-sandboxen er særligt nyttig til ressourcetunge opgaver, du vil køre parallelt uden at belaste din egen maskine, eller når du vil fortsætte en session på tværs af enheder. Husk dog, at lokal sandboxing ikke gælder for cloud-sessioner eller sessioner på en ekstern host, de to mekanismer er adskilte, og du skal forholde dig til dem hver for sig.

Byg et komplet eksempelprojekt med en sandboxed agent

For at se forskellen i praksis bygger vi et lille Node.js-script, der henter vejrdata, og vi lader en sandboxed agent udføre opgaven, mens vi aktivt nægter den adgang til mapper uden for projektet. Start med at oprette en projektmappe og initialisere den som et almindeligt Node.js-projekt.

# Opret projektmappen
mkdir vejr-agent-demo && cd vejr-agent-demo
npm init -y

# Start en sandboxed Copilot CLI-session i mappen
copilot
/sandbox enable

Bed herefter agenten om at oprette en fil kaldet index.js, der bruger Node.js’ indbyggede fetch til at hente data fra et offentligt API og udskrive resultatet. Da sandboxen som udgangspunkt kun giver læs/skriv-adgang til selve projektmappen, kan agenten oprette og redigere filer i vejr-agent-demo, men den kan ikke røre filer i din hjemmemappe eller i andre projekter, selv hvis den instruktion, du giver den, skulle indeholde en fejl eller en forsøgt omgåelse.

Sådan ser en typisk, vellykket session ud, når politikken tillader netværksadgang til det offentlige internet:

$ copilot
> /sandbox enable
Sandbox enabled for this session (filesystem: project-only, network: internet allowed)

> Opret index.js der henter data fra et offentligt API og udskriver resultatet
Opretter index.js...
Fil oprettet: /vejr-agent-demo/index.js
Kører: node index.js
Output: { temperatur: 14, by: "Aarhus" }
Session afsluttet uden adgangsfejl

Prøv nu at stramme politikken, så den nægter netværksadgang, og bed agenten om den samme opgave igen. Resultatet viser tydeligt, hvorfor sandboxen fejler lukket frem for åbent:

$ copilot
> /sandbox enable --no-network
Sandbox enabled for this session (filesystem: project-only, network: denied)

> Kør index.js
Kører: node index.js
Fejl: fetch failed - network access denied by sandbox policy
Kommandoen blev afvist af sandbox-politikken, ikke af Node.js selv

Denne lille øvelse viser forskellen mellem en fejl i din kode og en fejl, sandboxen bevidst har fremtvunget. Når du fejlfinder senere, er det første, du bør tjekke, netop om en fejlmeddelelse kommer fra din applikation eller fra selve sandbox-politikken.

Når du er tilfreds med resultatet, bør package.json i projektet se nogenlunde sådan ud. Læg mærke til, at agenten ikke har tilføjet afhængigheder ud over Node.js’ indbyggede fetch, netop fordi sandbox-politikken begrænsede, hvad den kunne installere, uden at du eksplicit godkendte det.

{
  "name": "vejr-agent-demo",
  "version": "1.0.0",
  "main": "index.js",
  "type": "module",
  "scripts": {
    "start": "node index.js"
  }
}

Afslut øvelsen ved at rydde op og slå sandboxing fra igen, hvis du ikke skal bruge projektet videre. Det er god praksis altid at lade en session slutte i en kendt tilstand, så du ikke bliver overrasket af en politik, der stadig er aktiv, næste gang du åbner mappen.

# Afslut sessionen og ryd op
/sandbox off
exit

Tjekliste: fra nul til beskyttet agent

Har du fulgt guiden fra start til her, har du nu dækket alle de centrale trin. Brug listen herunder som en hurtig tjekliste, næste gang du sætter et nyt projekt op, eller når du skal forklare processen til en kollega.

Installér eller opdatér Copilot CLI med npm install -g @github/copilot, og bekræft med copilot –version.
Log ind med copilot auth login, og bekræft at din organisation har aktiveret CLI-politikken, hvis du er på Business eller Enterprise.
Start en session i dit projekt, og slå sandboxing til med /sandbox enable.
Test med en simpel opgave, og bekræft at agenten ikke kan tilgå filer uden for projektmappen.
Sæt tilsvarende politik op i VS Code, og bekræft at sessionen kører via Agent Host.
Åbn Copilot-appens indstillinger, vælg dit projekt, og slå “Sandbox new sessions” til.
Gennemgå filsystem-politikken, og nægt eksplicit adgang til hjemmemappe og SSH-nøgler.
Beslut, om netværksadgang skal være tilladt, baseret på om opgaven kræver pakkeinstallation.
Beslut, om Git- og GitHub CLI-credentials skal være tilgængelige for den konkrete opgave.
Hvis du er administrator, konfigurér enterprise-managed settings via Intune eller en anden MDM-platform.
Aktivér eventuelt den organisationsstyrede JetBrains-preview, hvis dit team bruger JetBrains-IDE’er.
Test et realistisk projekt, log resultaterne, og juster politikken, før du ruller den ud bredt.

5 almindelige faldgruber, når du sætter sandboxing op

At forveksle CLI-sandboxing med app-sandboxing. De to overflader konfigureres hver for sig, så en politik du har sat i Copilot-appen, gælder ikke automatisk i en CLI-session i samme mappe.
At tro, sandboxing dækker kommandoer du selv skriver. Politikken gælder kun værktøjer og kommandoer, agenten selv igangsætter, ikke alt hvad der sker i terminalvinduet.
At glemme, at indstillinger kun gælder nye sessioner. Ændrer du politikken i et projekt i Copilot-appen, påvirker det ikke sessioner, der allerede kører, før de genstartes.
At give for bred læs/skriv-adgang af bekvemmelighed. Det er fristende at tillade adgang til hele hjemmemappen for at undgå gentagne godkendelser, men det ophæver i praksis formålet med sandboxen.
At antage, lokal sandboxing også dækker cloud-sessioner. De to sandbox-typer er adskilte systemer med hver sin politik, og en lokal nægtelse flytter ikke automatisk med til en cloud-session.

Fejlfinding: 8 problemer og løsninger

Her er de problemer, du oftest støder på, når du arbejder med lokal sandboxing, og hvordan du løser dem.

Sandboxed shell starter slet ikke. Dit styresystem kan sandsynligvis ikke håndhæve den ønskede politik. Sandboxen fejler med vilje lukket i stedet for at køre ubeskyttet, så tjek om du kører en understøttet version af Windows, macOS eller Linux.
/sandbox enable virker ikke i CLI’en. Bekræft at du kører den nyeste version af @github/copilot med copilot –version, da ældre versioner mangler kommandoen.
Agenten kan ikke skrive filer, selv i projektmappen. Tjek om en organisationspolitik overskriver dine lokale indstillinger. Hvis din administrator har låst filsystem-politikken, kan du ikke selv udvide den.
Netværkskald fejler uventet under en almindelig npm install. Det sker, hvis sandboxen er sat til at nægte udgående internetadgang. Udvid politikken midlertidigt, eller kør installationen uden for en sandboxed session.
Git push fejler med en godkendelsesfejl inde fra agenten. Det er sandsynligvis credential-politikken, der nægter adgang til dine Git-legitimationsoplysninger. Du skal eksplicit tillade det i projektets sandbox-indstillinger.
Indstillinger i Copilot-appen slår ikke igennem. Husk at ændringer kun gælder nye sessioner eller sessioner, der genstartes, ikke sessioner der allerede kører.
JetBrains viser ingen sandbox-indstillinger overhovedet. Funktionen er stadig i offentlig preview og kræver, at din organisation har slået Editor Preview-feature-flaget til, eller selv har konfigureret en administreret indstilling.
Du er usikker på, om en fejl skyldes din kode eller sandboxen. Se efter en eksplicit besked om, at en kommando blev afvist af sandbox-politikken. Den adskiller sig fra almindelige kørselsfejl og nævner typisk politikken direkte.

Hvorfor sikkerhed omkring AI-agenter er blevet mere presserende

Lokal sandboxing kommer ikke ud af ingenting. Jo mere autonomt en kodeagent arbejder, jo større er konsekvensen, hvis den bliver manipuleret eller simpelthen misforstår en opgave. Et forkert fortolket prompt kan i værste fald betyde, at en kommando sletter filer uden for projektet, læser hemmeligheder fra en .env-fil, eller sender data til et sted, du ikke havde forventet. Det gælder uanset om agenten kører lokalt via Copilot eller via et tredjepartsværktøj.

Vi har tidligere skrevet om, hvordan angreb mod MCP-servere og AI-kodeagenter kan udnytte netop den slags brede systemadgang, blandt andet i vores dækning af GhostSplice-angrebet mod AI-kodeassistenter. Pointen i den sammenhæng er den samme som her: når en agent kan nå internettet, dine credentials og hele filsystemet på én gang, bliver den et attraktivt mål, selv hvis selve AI-modellen er sikker nok. Lokal sandboxing ændrer ikke på, hvor god modellen er til at skrive kode, men den ændrer markant på, hvor meget skade en fejl, et hul i en afhængighed, eller et bevidst angreb kan nå at gøre, før nogen opdager det.

Avancerede tips til produktionsbrug

Når du har fået grundopsætningen til at virke, er der flere greb, der gør sandboxing mere holdbart i en rigtig teamhverdag. Start med at lade et par erfarne udviklere teste en strammere politik i et par uger, før du ruller den ud organisationsbredt via Intune eller en anden MDM-platform. Det afslører hurtigt, hvilke legitime arbejdsgange en for stram politik ved et uheld blokerer.

Differentier politikker efter projekttype

Et internt backend-projekt med adgang til en lokal database har andre behov end et åbent bidrag til et eksternt open source-projekt, hvor du bør være markant mere restriktiv med netværk og credentials. Da Copilot-appen konfigurerer sandboxing pr. projekt, er det oplagt at holde en stram standardpolitik for nye, ukendte projekter og kun løsne den, når du selv har vurderet tilliden til koden. Et praktisk mønster er at starte alle nye klonede repositories med nægtet netværksadgang og kun projektmappen i læs/skriv, og først løsne politikken, når du har læst gennem koden og ved, hvad den rent faktisk gør.

Overvåg og dokumentér, hvad politikkerne faktisk fanger

Brug enterprise policy-diagnosticering, hvis din organisation har den tilgængelig i JetBrains-integrationen, til løbende at bekræfte, at politikker rent faktisk bliver registreret og håndhævet på de enkelte udviklermaskiner. Det er langt hurtigere end at opdage et hul manuelt, efter en hændelse allerede er sket. Det er desuden en god idé at logge, hvor ofte sandboxen faktisk afviser en kommando i praksis. Afviser den næsten aldrig noget, er politikken muligvis for bred til at gøre en reel forskel. Afviser den konstant legitime opgaver, er den formentlig for stram, og udviklerne ender med at slå sandboxing fra i frustration, hvilket underminerer hele formålet. Endelig: kombinér sandboxing med de agent-tilladelser, GitHub har tilføjet til Copilot, så du både styrer, hvilke handlinger agenten må foreslå, og hvad den rent faktisk kan udføre, hvis den får lov.

GitHub Spark er lukket: sandboxing er det nye svar på app-sikkerhed

Det er værd at nævne, hvorfor denne funktion kommer nu. GitHub lukkede sit tidligere forsøg på naturlig sprog-til-app-byggeri, GitHub Spark, for nye brugere den 4. august 2026, og eksisterende brugere mistede adgangen til at redigere deres apps efter 31. august 2026, som det fremgår af GitHubs egen meddelelse om udfasningen. GitHub skriver selv, at AI-modeller og agentiske udviklingsværktøjer siden Sparks lancering er blevet markant bedre, og at byggere i stigende grad vælger de integrerede arbejdsgange i VS Code, Copilot CLI og Copilot-appen frem for en separat app-bygger. Prisen for Copilot selv er uændret af den udvikling, og du kan se de fulde planer i vores gennemgang af Copilots opsætning.

Det giver et klart billede af retningen: GitHub satser ikke længere på isolerede eksperimenter som Spark, men på at gøre de eksisterende, meget brugte overflader, CLI, app og editor, mere sikre at bruge agentisk. Lokal sandboxing er en direkte konsekvens af den strategi, og det er sandsynligvis derfor, funktionen er rullet ud bredt og uden ekstra pris, frem for som et nyt, separat produkt.

Ofte stillede spørgsmål

Koster lokal sandboxing ekstra oven i min Copilot-plan?
Nej. GitHub oplyser i sin changelog, at lokal sandboxing er inkluderet med GitHub Copilot uden ekstra pris, uanset om du er på Free, Pro, Pro+, Business eller Enterprise.

Kræver sandboxing Docker eller en virtuel maskine?
Nej. Funktionen bygger på Microsoft eXecution Container (MXC), som bruger styresystemets egne isoleringsmekanismer direkte på Windows, macOS og Linux, uden at du skal installere og vedligeholde en separat container-platform.

Er lokal sandboxing det samme som “Sandkasse”-programmet med nye modeller?
Nej, det er to forskellige funktioner. Model-sandkassen lader dig teste eksperimentelle modeller, mens lokal sandboxing isolerer, hvad agentens kommandoer må tilgå på din maskine, uanset hvilken model du bruger.

Kan min arbejdsgiver tvinge sandboxing til at være slået til?
Ja, hvis organisationen er på Copilot Business eller Enterprise. Administratorer kan kræve sandboxing centralt og håndhæve politikker via enterprise-managed settings, distribueret gennem Microsoft Intune eller andre MDM-platforme, og du kan ikke selv svække dem.

Virker sandboxing også, når jeg bruger Copilot med Claude eller OpenAI Codex som model?
Ja. GitHub understreger, at modeludførelse og værktøjsisolering er to adskilte spørgsmål, og at sandbox-politikker gælder for værktøjsudførelsen uanset hvilken model Copilot bruger i sessionen.

Hvad sker der, hvis mit styresystem ikke kan håndhæve den politik, jeg har sat op?
Den sandboxede shell nægter at køre og fejler med en tydelig fejlmeddelelse, i stedet for stiltiende at falde tilbage til en ubeskyttet session. Det er et bevidst designvalg fra GitHub, så du aldrig tror, du er beskyttet, uden at være det.

Er lokal sandboxing tilgængelig i JetBrains-IDE’er?
En organisationsstyret udgave kom i offentlig preview den 8. september 2026 for JetBrains-brugere, men selve GA-annonceringen fra 7. oktober 2026 navngiver eksplicit Copilot CLI, Copilot-appen og VS Code-sessioner med Agent Host som de understøttede overflader ved generel tilgængelighed.

Hvor kan jeg læse den officielle dokumentation?
GitHub har samlet konceptet under “About cloud and local sandboxes for GitHub Copilot” i den officielle dokumentation, mens selve GA-annonceringen ligger i GitHub Changelog under overskriften om lokal sandboxing fra 7. oktober 2026.

Skal jeg vælge lokal sandboxing eller cloud-sandboxen?
Det afhænger af opgaven. Vælg lokal sandboxing til almindeligt, dagligt arbejde i et projekt du kender, hvor du vil beholde kontrollen og hastigheden ved at arbejde på din egen maskine. Vælg cloud-sandboxen via copilot –cloud, når du skal køre ressourcetunge eller mindre betroede opgaver fuldt isoleret fra din egen hardware, eller når du vil kunne fortsætte en session fra en anden enhed.

Kan jeg bruge lokal sandboxing sammen med MCP-servere?
Ja. GitHub oplyser, at sandboxing kan anvendes på lokale værktøjer og tjenester, inklusive lokale MCP-servere og sprogservere, hvor det er understøttet, så den samme politik for filsystem og netværk også begrænser, hvad en tilkoblet MCP-server kan foretage sig på dine vegne.

GitHub Copilot Lokal Sandbox: 12 Trin, 45 Min [2026]