GitHub Copilot har i august og september 2026 fået en bunke nye agent-funktioner, og en af de mest praktiske er muligheden for at køre coding-agenten inde i en Dev Container. Det betyder, at agenten arbejder i præcis det samme miljø som resten af holdet, med de rigtige versioner af Node, Python eller Go, uden at du selv skal installere noget lokalt. I denne guide sætter vi det hele op fra bunden: Docker, en devcontainer.json-fil, VS Code 1.136 og selve agent-workflowet, inklusive den nye Agent Merge-funktion til at rydde op i konflikter og fejlede tjek.
Guiden er skrevet til udviklere, der allerede bruger GitHub Copilot til autocomplete og chat, men endnu ikke har prøvet den fulde agent-oplevelse med et isoleret, reproducerbart miljø. Vi bruger cirka 50 minutter på opsætningen, og du ender med et komplet, kørende eksempelprojekt, hvor Copilot selv retter en fejl, kører tests og opretter et pull request.
Behovet for det her opstår typisk i det øjeblik, et team flytter fra “Copilot som en smart autocomplete” til “Copilot som en agent, der løser hele opgaver selvstændigt”. Så snart agenten skal køre tests, bygge projektet eller installere afhængigheder, betyder miljøet pludselig noget. En agent, der kører i et fremmed cloud-sandkasse-billede uden adgang til firmaets interne npm-registry eller den rigtige databaseversion, ender ofte med at fejle på ting, der intet har med selve koden at gøre. Dev Containers løser præcis det problem, og det er derfor funktionen er blevet en af de mest efterspurgte i Copilot-fora siden den begyndte at rulle ud.
Hvad er GitHub Copilot Dev Containers, og hvorfor bruge dem
Dev Containers er en åben specifikation, som VS Code, GitHub Codespaces og nu også Copilots coding-agent læser fra samme fil: .devcontainer/devcontainer.json. Filen beskriver hvilket basisbillede projektet skal køre i, hvilke VS Code-udvidelser der skal med, og hvilke kommandoer der skal køre, når containeren starter. Når Copilots agent får adgang til denne fil, henter den præcis det samme miljø, som du selv udvikler i, i stedet for et generisk sandkasse-billede i skyen.
Det løser et problem, mange teams har oplevet med tidligere versioner af Copilots baggrundsagent: den kørte i et isoleret cloud-miljø uden adgang til interne pakker, specifikke compiler-versioner eller lokale test-fixtures. Ifølge GitHubs eget changelog rulles lokal Dev Container-kørsel for agenter ud gradvist i VS Code, og kræver Docker plus en understøttet devcontainer-konfiguration i repoet. Funktionen kom sammen med en række andre agent-opdateringer i september 2026, herunder tre nye model-valg-niveauer kaldet Efficiency, Balance og Intelligence, som styrer afvejningen mellem pris, kvalitet og svartid, uden at du selv skal vælge en bestemt model hver gang.
Samtidig fik VS Code 1.136 en funktion ved navn Agent Merge i offentlig preview. Den er bygget til at hjælpe med at løse reviewkommentarer, fejlede CI-tjek og merge-konflikter, før en agent-genereret ændring bliver merget ind. Kombinationen af de to funktioner, lokal container-kørsel og automatisk konfliktløsning, er det, der gør september 2026-versionen af Copilot til noget markant anderledes end blot “autocomplete med chat”.
Dev Container vs. GitHub Codespaces: hvad er forskellen
Mange forveksler de to, fordi de deler samme konfigurationsfil. Forskellen ligger i, hvor containeren kører. Med GitHub Codespaces kører containeren på GitHubs egne servere, og du tilgår den gennem browseren eller en let VS Code-klient. Med den lokale Dev Container-tilgang, som denne guide bruger, kører containeren på din egen maskine gennem din lokale Docker-installation. Det giver hurtigere filadgang, ingen afhængighed af internetforbindelse for selve kørslen, og ingen løbende cloud-regning for compute-tid. Til gengæld skal din egen maskine kunne bære byggeprocessen, hvilket sjældent er et problem for almindelige webprojekter, men kan mærkes på store monorepos med tunge compileringstrin.
Fordelen ved, at Copilots agent understøtter begge dele, er, at du kan starte lokalt under udvikling og senere flytte de samme planlagte eller tilbagevendende agent-opgaver over i Codespaces, hvis teamet vokser og har brug for delt, centraliseret compute i stedet for at hver udvikler kører sin egen lokale container.
Forudsætninger og versioner
Før du starter, skal følgende være på plads. Tjek versionerne nøje, da agent-funktionerne kun virker fra bestemte udgivelser og opefter.
| Komponent | Minimumsversion | Bemærkning |
|---|---|---|
| Visual Studio Code | 1.136 eller nyere | Agent Merge og multi-root agent-sessioner kræver denne udgave |
| GitHub Copilot-udvidelsen | Nyeste fra Marketplace | Opdateres automatisk, men tjek manuelt før du starter |
| GitHub Copilot Chat-udvidelsen | Nyeste fra Marketplace | Kræves for agent-tilstand og Agents-vinduet |
| Docker Desktop eller Docker Engine | Nyeste stabile | Skal køre, før agenten kan starte en lokal container |
| Git | 2.40 eller nyere | Bruges til branch-håndtering og Agent Merge |
| Node.js | 20 LTS | Bruges i eksempelprojektet i denne guide |
| GitHub-konto med Copilot-abonnement | Pro, Pro+, Business eller Enterprise | Coding-agenten kræver et betalt niveau, ikke den gratis prøveperiode alene |
Du behøver ikke en kraftig maskine. En bærbar med 16 GB RAM er rigeligt til at køre både VS Code, en let Docker-container og en Node-server samtidig. Har du kun 8 GB RAM, bør du lukke andre tunge programmer, mens agenten arbejder, da Docker Desktop selv lægger beslag på et par gigabyte.
Trin 1: Installer og opdater VS Code
Hent VS Code fra den officielle side, hvis du ikke allerede har det. Har du det, skal du sikre dig, at du kører 1.136 eller nyere, da ældre versioner mangler både Agent Merge og de nye Dev Container-integrationer. Åbn kommandopaletten (Ctrl+Shift+P på Windows/Linux, Cmd+Shift+P på macOS), skriv “Check for Updates” og installer eventuelle opdateringer.
code --version
# Forventet output, tre linjer: versionsnummer, commit-hash, arkitektur
# 1.136.0
# a1b2c3d4e5f6...
# x64Hvis versionsnummeret er lavere end 1.136, skal du opdatere manuelt via Hjælp-menuen eller downloade den nyeste installer. På Linux med apt-pakken kan du køre en almindelig pakkeopdatering, mens Snap- og Flatpak-brugere skal opdatere via deres respektive pakkehåndteringer.
Trin 2: Installer Docker og bekræft at det kører
Dev Containers kræver en kørende container-runtime. De fleste vælger Docker Desktop på Windows og macOS, mens Linux-brugere ofte kører Docker Engine direkte. Installer det, og bekræft derefter at daemonen svarer:
docker --version
docker run hello-world
# Forventet output slutter med:
# Hello from Docker!
# This message shows that your installation appears to be working correctly.Ser du i stedet en fejl om, at daemonen ikke kan nås, er Docker Desktop sandsynligvis ikke startet endnu. Åbn programmet, vent til ikonet i statusfeltet viser en grøn status, og prøv kommandoen igen. På virksomheds-pc’er med gruppepolitikker kan virtualisering (Hyper-V eller WSL2 på Windows) være slået fra som standard, hvilket kræver, at en it-administrator aktiverer det.
Trin 3: Installer og log ind på GitHub Copilot-udvidelserne
Åbn Extensions-panelet i VS Code (Ctrl+Shift+X), søg efter “GitHub Copilot” og installer både hoved-udvidelsen og Copilot Chat. Log ind med din GitHub-konto, når VS Code beder om det, og godkend adgangen i browservinduet, der åbner. Bekræft bagefter, at Copilot-ikonet i statuslinjen nederst til højre viser en grøn markering og ikke en advarselstrekant.
Har du et Business- eller Enterprise-abonnement, skal en organisationsadministrator have aktiveret coding-agent-funktionen for din organisation, før den dukker op i din editor. Det gøres under organisationens Copilot-indstillinger på github.com, ikke i selve VS Code.
Trin 4: Opret eksempelprojektet
Vi bygger et lille Express-API med en bevidst fejl, som agenten skal finde og rette senere i guiden. Opret en ny mappe og et minimalt Node.js-projekt:
mkdir copilot-devcontainer-demo
cd copilot-devcontainer-demo
npm init -y
npm install express
npm install --save-dev jest supertest
git init
git add .
git commit -m "Initial commit"Opret derefter filen server.js med et simpelt endpoint og en test-fil, der forventer et bestemt svar:
// server.js
const express = require('express');
const app = express();
app.get('/api/status', (req, res) => {
res.json({ status: 'ok', version: 1 }); // Bevidst forkert nøglenavn
});
app.listen(3000, () => console.log('Server kører på port 3000'));
module.exports = app;// server.test.js
const request = require('supertest');
const app = require('./server');
test('GET /api/status returnerer korrekt struktur', async () => {
const res = await request(app).get('/api/status');
expect(res.body).toEqual({ status: 'ok', apiVersion: 1 });
});Testen forventer feltet apiVersion, men serveren returnerer version. Det er den fejl, agenten skal finde og rette senere. Commit koden, så du har et rent udgangspunkt.
Trin 5: Skriv en devcontainer.json-fil
Opret mappen .devcontainer i projektroden og en fil ved navn devcontainer.json. Det er denne fil, både VS Code og Copilots agent læser for at vide, hvilket miljø de skal starte.
{
"name": "copilot-devcontainer-demo",
"image": "mcr.microsoft.com/devcontainers/javascript-node:20",
"features": {
"ghcr.io/devcontainers/features/git:1": {}
},
"customizations": {
"vscode": {
"extensions": [
"github.copilot",
"github.copilot-chat",
"dbaeumer.vscode-eslint"
]
}
},
"postCreateCommand": "npm install",
"forwardPorts": [3000],
"remoteUser": "node"
}Feltet postCreateCommand sikrer, at afhængighederne installeres, hver gang containeren bygges op fra bunden. forwardPorts gør, at port 3000 automatisk videresendes til din vært, så du kan teste API’et i browseren, selv om det kører inde i containeren. Commit filen til git, da agenten skal kunne se den fra repoets historik.
Trin 6: Åbn projektet i containeren og verificér miljøet
Åbn kommandopaletten og vælg “Dev Containers: Reopen in Container”, som findes efter du har installeret Dev Containers-udvidelsen. VS Code bygger nu billedet, installerer udvidelserne og kører postCreateCommand. Første gang tager det typisk 1-3 minutter, afhængigt af din internetforbindelse, da basisbilledet skal hentes ned.
# Kør i terminalen inde i containeren, for at bekræfte miljøet
node --version
npm --version
npx jest --versionKør testen for at bekræfte, at fejlen fra trin 4 stadig er der:
npx jest
# Forventet output:
# FAIL ./server.test.js
# ✕ GET /api/status returnerer korrekt struktur
# Expected: {"apiVersion": 1, "status": "ok"}
# Received: {"status": "ok", "version": 1}Trin 7: Tildel en opgave til Copilots coding-agent
Push projektet til et GitHub-repo, hvis du ikke allerede har gjort det. Åbn derefter Copilot Chat-panelet i VS Code, skift til agent-tilstand (vælges i dropdown-menuen øverst i chatvinduet), og giv agenten en konkret, afgrænset opgave. GitHubs egen dokumentation om at tildele opgaver til coding-agenten anbefaler, at opgaven er så snæver og konkret som muligt, netop for at undgå at agenten begynder at gætte sig frem til, hvad du mener:
@agent Testen i server.test.js fejler, fordi server.js returnerer
feltet "version" i stedet for "apiVersion". Ret server.js så
testen består, kør testen for at bekræfte, og opret et pull
request med rettelsen.Med Dev Container-integrationen slået til kører agenten opgaven i samme container, som du selv sidder i, med adgang til de samme npm-pakker og den samme Node-version. Det betyder, at agentens egen testkørsel er repræsentativ for, hvad der reelt sker, når koden merges, i modsætning til et generisk cloud-sandkasse-miljø, der måske ikke har de samme afhængigheder installeret.
Trin 8: Vælg det rigtige model-niveau til opgaven
September 2026-opdateringen introducerede tre automatiske model-valg-niveauer: Efficiency, Balance og Intelligence. Alle tre vælger fra den samme pulje af tilgængelige modeller, men vægter forskelligt mellem pris, kvalitet og svartid. Til en lille, veldefineret rettelse som vores er Efficiency som regel rigeligt og hurtigst. Til større refaktoreringer på tværs af flere filer bør du skifte til Intelligence, som bruger mere tid på at overveje sideeffekter.
| Niveau | Bedst til | Typisk brug |
|---|---|---|
| Efficiency | Små, afgrænsede rettelser og enkle opgaver | Bugfixes, typefejl, mindre refaktoreringer |
| Balance | Standard dagligt arbejde | Nye funktioner af middel størrelse, testdækning |
| Intelligence | Komplekse, flertrins-opgaver | Arkitekturændringer, migrationer, sikkerhedsrettelser |
Du kan stadig vælge en specifik model manuelt, hvis du foretrækker det. Blandt de modeller, der er rullet ud i Copilot i løbet af august og september 2026, er Claude Fable 5.1 (Pro+, Max, Business og Enterprise), Gemini 3.8 Flash, Grok 4.7 og Kimi K3. Hvilke der er tilgængelige, afhænger af dit abonnementsniveau, så tjek GitHubs egen modeloversigt i Copilot-indstillingerne, før du planlægger et workflow omkring en bestemt model.
Modelvalget har direkte betydning for, hvor godt Dev Container-opsætningen udnyttes. En reasoning-tung model som Grok 4.7, der ifølge GitHub er bygget til agentisk kodning og komplekse, flertrins-workflows, har mere gavn af at kunne køre rigtige kommandoer og se rigtige testresultater i en ægte container end en hurtig, letvægts-model, der primært foreslår kodeændringer uden selv at eksekvere dem. Har du valgt Efficiency-niveauet til en opgave, der viser sig at kræve flere trin, kan du undervejs skifte til Balance eller Intelligence uden at miste agentens hidtidige fremskridt.
Trin 9: Følg agentens fremgang i Agents-vinduet
Mens agenten arbejder, kan du følge med i det dedikerede Agents-vindue i VS Code. Det viser opgavens status, hvilke filer der er ændret, og terminaloutput fra kommandoer, agenten kører. En nyere tilføjelse gør, at vinduet kan vise issue- og pull request-detaljer, selv når det tilhørende repo ikke er åbent i editoren, hvilket er praktisk, hvis du styrer agenter på tværs af flere projekter samtidig.
Bliver du utålmodig eller opdager, at agenten er på vej i en forkert retning, kan du afbryde og omdirigere den midt i en session i stedet for at vente på, at hele opgaven fuldføres og derefter starte forfra. Det sparer typisk flere minutter på opgaver, hvor den indledende plan viser sig at være forkert.
Trin 10: Gennemgå diffen og kør testene selv
Når agenten melder opgaven færdig, skal du ikke bare stole blindt på den. Åbn diff-visningen i VS Code og gennemgå ændringerne linje for linje. I vores eksempel bør ændringen være minimal:
// server.js, efter agentens rettelse
app.get('/api/status', (req, res) => {
res.json({ status: 'ok', apiVersion: 1 });
});Kør testen igen i terminalen for at bekræfte selv, uafhængigt af agentens egen rapportering:
npx jest
# Forventet output:
# PASS ./server.test.js
# ✓ GET /api/status returnerer korrekt struktur (24 ms)Denne dobbelttjek er ikke overflødig forsigtighed. Selv med et godt model-valg kan en agent nogle gange “rette” en test ved at ændre testens forventning i stedet for den underliggende fejl, hvilket teknisk set får testen til at bestå uden at løse det faktiske problem.
Trin 11: Brug Agent Merge til at håndtere konflikter og fejlede tjek
Agent Merge, som kom i offentlig preview med VS Code 1.136, er lavet til situationer, hvor agentens pull request enten får reviewkommentarer, fejler et CI-tjek, eller kommer i konflikt med hovedgrenen, fordi andre har committet i mellemtiden. I stedet for at du manuelt skal rebase, løse konflikter og pushe igen, kan du bede agenten tage over:
@agent Pull requestet har en merge-konflikt mod main, og CI-tjekket
"lint" fejler med to ESLint-advarsler. Løs konflikten, ret
lint-fejlene, og push den opdaterede branch.Fordi funktionen stadig er i preview, bør du behandle den som et hjælpemiddel og ikke en automatisk godkendelsesmekanisme. Sæt branch protection-regler op, så et pull request stadig kræver mindst én menneskelig godkendelse, uanset om Agent Merge har rettet konflikten. Det er særligt vigtigt på delte repos, hvor flere agenter fra forskellige teammedlemmer kan arbejde på overlappende dele af kodebasen samtidig.
Trin 12: Planlæg tilbagevendende agent-opgaver
Ud over enkeltstående opgaver understøtter Copilot nu planlagte agent-opgaver i offentlig preview. Du kan sætte en agent til at køre en fast opgave hver time, dagligt eller ugentligt, eller udløse den manuelt efter behov. Det er relevant til ting som at holde afhængigheder opdateret, generere ugentlige changelog-opsummeringer, eller tjekke for forældede TODO-kommentarer i kodebasen.
Opsætningen foregår gennem Copilot-agentens planlægningsmenu i GitHub-webgrænsefladen, hvor du definerer prompten, gentagelsesfrekvensen og hvilket repo opgaven skal køre imod. Kombinér den gerne med Dev Container-opsætningen fra tidligere i guiden, så de planlagte opgaver også kører i det korrekte, versionsstyrede miljø frem for et generisk billede.
Trin 13: Byg videre med Copilot-hukommelse og projektinstruktioner
Den sidste byggeklods er Copilot-hukommelse, som gemmer relevante projektdetaljer og dine præferencer på tværs af agent-chat-sessioner, så du ikke skal gentage samme kontekst hver gang. Kombinér det med en fil ved navn .github/copilot-instructions.md i repoets rod, hvor du beskriver kodestandarder, testkrav og hvilke mapper agenten aldrig må røre:
# .github/copilot-instructions.md
- Kør altid `npx jest` efter enhver ændring, før du opretter et PR.
- Rør aldrig filer under /legacy uden eksplicit tilladelse.
- Brug altid apiVersion, ikke version, i JSON-svar fra API'et.
- Skriv commit-beskeder på engelsk, PR-beskrivelser på dansk.Denne fil læses automatisk af agenten ved hver ny opgave og fungerer som en slags stående ordre, der reducerer antallet af gange, du skal rette samme type fejl i agentens output. Arbejder du på tværs af flere agent-værktøjer, kan du kombinere den med Agent Plugins, så den samme opsætning kan genbruges i VS Code, Copilot CLI og Copilot-appen.
Eksempel 2: lad agenten tilføje en ny funktion fra bunden
Bugfixet fra tidligere i guiden er et godt første eksempel, men det er en meget lille opgave. For at se, hvordan Dev Container-opsætningen holder ved lidt større opgaver, kan du bede agenten om at tilføje et helt nyt endpoint med tilhørende test, i stedet for blot at rette en eksisterende fejl:
@agent Tilføj et nyt endpoint GET /api/health, der returnerer
{"healthy": true, "uptimeSeconds": }. Skriv en tilhørende test
i en ny fil health.test.js, kør hele testsuiten, og opret et
pull request, hvis alle tests består. Denne opgave kræver, at agenten selv finder ud af, hvordan projektets eksisterende kodestil ser ud (baseret på server.js), opretter en ny fil efter samme mønster som den eksisterende test, og kører hele testsuiten, ikke kun den nye test, for at sikre at intet andet er gået i stykker undervejs. Fordi agenten kører inde i den samme Dev Container, har den adgang til den præcis samme version af Jest og Supertest, som resten af projektet bruger, hvilket betyder, at dens egen testkørsel er et pålideligt signal, før du selv skal kigge på koden.
Når pull requestet er oprettet, er arbejdsgangen den samme som i det første eksempel: gennemgå diffen, kør testene selv i din egen container-session, og godkend først, når du er tilfreds. På denne størrelse opgave er det værd at bruge Balance-niveauet fra model-tabellen tidligere i guiden i stedet for Efficiency, da opgaven involverer at oprette en ny fil og forstå eksisterende konventioner, ikke blot rette en enkelt linje.
Sådan placerer Dev Containers sig blandt konkurrerende agent-værktøjer
Copilot er langtfra det eneste agent-værktøj, der er begyndt at tage lokale og isolerede kørselsmiljøer alvorligt. Cursor har i samme periode udvidet sin cloud-agent-arkitektur med Self-Hosted Machines, hvor teams kan køre agenter på egen infrastruktur, mens Cursor stadig står for selve planlægningen og orkestreringen. Cursor har også lanceret altid-tændte cloud-agenter, der kan reagere på events og holde langvarige mål kørende gennem komplekse sessioner, og en Cursor Router-funktion, der automatisk analyserer hver forespørgsel og sender den til den model, der passer bedst.
JetBrains går en anden vej og har i stedet udvidet sine enterprise-kontroller for Copilot direkte inde i JetBrains-produkterne, så organisationer kan styre agent-adgang centralt på tværs af IntelliJ, PyCharm og de øvrige IDE’er i familien. Forskellen på tilgangene er værd at kende, hvis du sidder med valget mellem flere værktøjer: Copilots Dev Container-tilgang optimerer for, at agenten arbejder i nøjagtig samme miljø som udvikleren, mens Cursors Self-Hosted Machines optimerer for, at agenten kan køre uafhængigt af, om nogen sidder ved tastaturet.
| Værktøj | Kørselsmiljø for agent | Nyeste relevante funktion |
|---|---|---|
| GitHub Copilot | Lokal Dev Container eller cloud-sandkasse | Dev Container-support og Agent Merge, begge i preview |
| Cursor | Cloud-agent eller Self-Hosted Machine | Altid-tændte cloud-agenter styret via Cursor Router |
| JetBrains AI Assistant | Lokal IDE-proces | Udvidede enterprise-kontroller for Copilot-integrationen |
Ingen af tilgangene er entydigt bedre end de andre. Er dit team allerede dybt investeret i VS Code og GitHub som platform, giver Dev Containers mest mening, fordi konfigurationen kan genbruges direkte til almindelig lokal udvikling, uden at du behøver vedligeholde to separate miljø-definitioner.
5 almindelige faldgruber
- Docker-daemonen kører ikke. VS Code viser en generisk fejl om, at containeren ikke kan bygges, i stedet for at sige direkte, at Docker mangler. Tjek altid
docker run hello-worldførst. - Forældet devcontainer.json fra et andet projekt. Kopierer du filen fra et gammelt projekt, kan basisbilledet pege på en Node-version, der ikke matcher dine faktiske afhængigheder, hvilket giver kryptiske npm-fejl under opbygning.
- Agenten mangler adgang til hemmeligheder. Miljøvariabler og API-nøgler, du normalt har i din lokale
.env-fil, følger ikke automatisk med ind i containeren, medmindre du eksplicit tilføjer dem viaremoteEnveller et secrets-værktøj. - For bred opgavebeskrivelse. Beder du agenten om at “forbedre kodekvaliteten” uden konkret afgrænsning, ender den ofte med at lave unødvendigt store, svært reviewbare ændringer på tværs af hele kodebasen.
- Blind tillid til Agent Merge i preview. Funktionen er stadig under udvikling, og du bør altid selv læse diffen efter en automatisk konfliktløsning, især i filer med forretningskritisk logik.
Fejlfinding: 8+ problemer og løsninger
De fleste problemer med denne opsætning falder i tre kategorier: Docker-relaterede byggefejl, forkerte antagelser i devcontainer.json, og situationer hvor agenten teknisk set løser opgaven forkert. Skemaet herunder samler de mest almindelige fejl, vi er stødt på under research til denne guide, sammen med den konkrete løsning, der virkede.
| Problem | Sandsynlig årsag | Løsning |
|---|---|---|
| “Reopen in Container” er grået ud | Dev Containers-udvidelsen mangler | Installer “Dev Containers” fra Extensions-panelet og genstart VS Code |
| Containeren bygger evigt uden at blive færdig | Langsom eller ustabil internetforbindelse under billed-download | Skift til et mindre basisbillede, eller byg billedet på forhånd og push det til et privat registry |
| Copilot-ikonet viser en advarselstrekant | Login-token er udløbet, eller organisationen har ikke aktiveret Copilot | Log ud og ind igen, og tjek organisationens Copilot-status på github.com |
| Agenten siger opgaven er løst, men testen fejler stadig | Agenten har rettet testens forventning i stedet for koden | Gennemgå diffen manuelt, afvis ændringen, og omformulér opgaven mere præcist |
| Port 3000 svarer ikke i browseren | forwardPorts mangler eller er forkert sat i devcontainer.json | Tilføj porten eksplicit og genopbyg containeren |
| npm install fejler under postCreateCommand | Node-versionen i basisbilledet matcher ikke package.json’s engines-felt | Justér basisbilledets tag, f.eks. fra node:18 til node:20 |
| Agent Merge kan ikke løse konflikten automatisk | Konflikten involverer semantisk modstridende ændringer, ikke kun tekstlige overlap | Løs konflikten manuelt og bed derefter agenten fortsætte fra det punkt |
| Planlagt agent-opgave kører ikke på det forventede tidspunkt | Tidszone-indstillingen i planlægningen matcher ikke din forventning | Tjek tidszonen i opgavens indstillinger på github.com, ikke din lokale systemtid |
| Copilot-hukommelse husker forældet information | Konteksten er ikke blevet ryddet efter en større refaktorering | Nulstil hukommelsen manuelt i Copilot-indstillingerne og opdatér copilot-instructions.md |
Avancerede tips til produktionsbrug
Når du flytter fra et testprojekt til et rigtigt produktionsrepo, er der et par ekstra ting værd at overveje. For det første bør du bygge og cache et eget devcontainer-billede i stedet for at basere dig på et generisk Microsoft-billede hver gang, især hvis projektet har mange systemafhængigheder ud over Node eller npm-pakker. Det reducerer byggetiden fra minutter til sekunder.
For det andet, brug content exclusions til at holde følsom kode ude af agentens synsfelt. Copilot app og CLI er blevet opdateret til at respektere content exclusions, så du kan udelukke mapper med hemmeligheder, kryptografiske nøgler eller regulatorisk følsom kode fra agentens arbejdsområde, selv når agenten ellers har adgang til resten af repoet.
For det tredje, hvis dit team arbejder med flere relaterede repos samtidig, understøtter VS Code 1.136 nu eksperimentel multi-root workspace-support for agent-sessioner. Det betyder, at en agent kan arbejde på tværs af et frontend- og et backend-repo i samme session, hvilket er nyttigt ved ændringer, der kræver samtidige opdateringer begge steder, som en API-kontrakt der ændrer sig.
Endelig, brug Copilot CLI’s headless-tilstand til CI-integration. Ved at kombinere --plan med --mode autopilot kan en agent lave en plan og derefter udføre den uden en interaktiv editor-session, hvilket gør det muligt at trigge agent-kørsler direkte fra en GitHub Actions-pipeline, for eksempel til automatisk at opdatere afhængigheder natligt.
Ressourceforbrug: hvad koster det at køre agenten lokalt
En lokal Dev Container lægger et ekstra lag oven på din normale udviklingsopsætning, og det mærkes primært to steder: diskplads og CPU under selve byggeprocessen. Basisbilledet javascript-node:20, som vi brugte i eksemplet, fylder typisk et par gigabyte, inklusive de forudinstallerede værktøjer. Har du flere projekter med hver deres devcontainer, kan diskforbruget hurtigt løbe op, medmindre du jævnligt rydder op med docker system prune.
# Ryd ubrugte images, containere og cache op
docker system prune -a
# Se hvor meget plads Docker fylder lige nu
docker system dfCPU-forbruget er som regel kun højt i de få minutter, hvor billedet bygges eller genbygges. Når containeren først kører, er belastningen sammenlignelig med at køre den samme kode direkte på værtsmaskinen, plus et mindre overhead fra selve virtualiseringslaget. På macOS med Apple Silicon og på Windows med WSL2 er overheadet i praksis lille nok til, at det ikke mærkes i en almindelig udviklerhverdag. Den reelle omkostning ved denne opsætning er derfor ikke compute, men den tid det tager at vedligeholde en devcontainer.json-fil, der rent faktisk afspejler produktionsmiljøet, efterhånden som projektets afhængigheder ændrer sig.
Sikkerhed og adgangsstyring omkring agent-containere
Fordi agenten nu kører i et lokalt miljø med adgang til dit filsystem og din Docker-installation, bør du behandle agent-tilladelser med samme omhu som du ville give en ny, midlertidig medarbejder. Undgå at give agenten adgang til produktionscredentials i containerens miljøvariabler, og brug i stedet separate, begrænsede test-nøgler under udvikling.
Sæt desuden branch protection op, så agent-genererede pull requests altid kræver mindst én menneskelig godkendelse, uanset om Agent Merge har løst eventuelle konflikter automatisk. På større organisationer bør en administrator også gennemgå, hvilke repos coding-agenten er aktiveret for, i stedet for at slå det til globalt for hele organisationen fra dag ét.
Et ofte overset punkt er, at devcontainer.json selv kan blive et angrebspunkt. Filen kan i princippet referere til et basisbillede fra et hvilket som helst registry, og hvis et repo modtager et pull request fra en ekstern bidragyder, der ændrer denne fil, kan en agent i teorien ende med at bygge og køre et ondsindet billede. Behandl derfor ændringer til .devcontainer/devcontainer.json som kodeændringer, der kræver samme reviewniveau som resten af kodebasen, ikke som ren konfiguration, der kan glide igennem uden ekstra opmærksomhed.
Sådan skalerer du opsætningen til et helt team
Når opsætningen fungerer for dig personligt, er næste skridt at committe devcontainer-konfigurationen og copilot-instructions.md-filen til det fælles repo, så hele teamet automatisk får samme miljø og samme regelsæt for agenten. Det fjerner en hel klasse af “det virker på min maskine”-problemer, fordi både mennesker og agenter nu arbejder i identiske containere.
Overvej også at oprette organisation-niveau brugerdefinerede agenter, en funktion der gør det muligt at standardisere, hvordan agenter bruges på tværs af flere teams, i stedet for at hvert team opfinder sine egne konventioner for prompts og instruktionsfiler. Det gør det nemmere for nye udviklere at komme i gang, fordi de arver et allerede gennemtestet agent-workflow i stedet for at skulle bygge det fra bunden.
Et praktisk sted at starte er at udpege et enkelt, mindre kritisk repo som pilotprojekt. Lad et par udviklere køre den fulde Dev Container-opsætning der i et par uger, saml op på, hvilke faldgruber fra listen tidligere i guiden der rent faktisk rammer jeres stack, og opdatér copilot-instructions.md løbende baseret på det. Når konfigurationen er stabil på pilotprojektet, er den langt hurtigere at kopiere ud til resten af organisationens repos, end hvis alle teams famler sig frem samtidig.
Sæt du de 13 trin sammen, har du et setup, hvor GitHub Copilots agent hverken gætter sig frem til dit miljø eller kører i et fremmed cloud-billede. Den arbejder i den samme container, du selv sidder i, retter reelle fejl, kører rigtige tests, og lader dig selv gennemgå diffen, før noget bliver merget. Det er ikke et setup, der fjerner behovet for kodereview, men det fjerner en stor del af friktionen mellem “agenten siger, det virker” og “det virker faktisk i vores miljø”.
Ofte stillede spørgsmål
Kræver Dev Container-integrationen et bestemt Copilot-abonnement?
Coding-agenten generelt kræver et betalt Copilot-niveau som Pro, Pro+, Business eller Enterprise. Selve Dev Container-funktionen ruller gradvist ud og kan derfor være tilgængelig på forskellige tidspunkter afhængigt af dit abonnement og din organisations indstillinger.
Kan jeg bruge Dev Containers uden Docker Desktop?
Ja, på Linux kan du bruge Docker Engine direkte uden Docker Desktop-grænsefladen. Det vigtige er, at en Docker-kompatibel daemon kører og kan tilgås af VS Code.
Er Agent Merge sikkert at bruge på produktionskode?
Funktionen er i offentlig preview, hvilket betyder, at den stadig ændrer sig og kan have begrænsninger. Brug den som et hjælpemiddel til at spare tid på simple, tekstlige konflikter, men behold altid krav om menneskelig godkendelse på pull requests, før de merges til hovedgrenen. Undlad at bruge den ukritisk på filer med forretningskritisk logik, betalingsflows eller adgangsstyring, hvor en forkert automatisk konfliktløsning kan have reelle konsekvenser.
Hvilken model bør jeg vælge til daglige opgaver?
Balance-niveauet er et godt udgangspunkt for de fleste daglige opgaver. Skift til Efficiency ved simple, veldefinerede rettelser, og til Intelligence ved komplekse opgaver som arkitekturændringer eller sikkerhedsrettelser.
Kan flere udviklere dele samme devcontainer.json?
Ja, det er faktisk hele pointen. Committer du filen til repoet, får alle teammedlemmer og agenten samme miljø, hvilket eliminerer forskelle mellem individuelle udviklermaskiner.
Hvad sker der, hvis containeren ikke kan bygge på grund af en netværksfejl hos agenten?
Agenten rapporterer typisk fejlen tilbage i Agents-vinduet med en log over, hvor byggeprocessen stoppede. Tjek om basisbilledet er tilgængeligt fra et offentligt registry, og om eventuelle private registries kræver godkendelse, agenten ikke har adgang til.
Kan jeg planlægge en agent-opgave til at køre hver nat uden at nogen overvåger den?
Teknisk set ja, men det anbefales at have notifikationer slået til, så du opdager, hvis en planlagt opgave begynder at fejle gentagne gange, i stedet for at opdage det uger senere.
Virker denne opsætning også med JetBrains-IDE’er i stedet for VS Code?
Copilot i JetBrains-produkter har fået udvidede enterprise-kontroller, men de specifikke Dev Container- og Agent Merge-funktioner beskrevet i denne guide er, ved denne artikels udgivelse, primært bygget til VS Code. Bruger dit team JetBrains som primær IDE, kan I stadig committe en devcontainer.json til repoet og bruge den til almindelig lokal udvikling, men selve agent-integrationen med containeren er endnu ikke lige så udbygget som i VS Code.
Hvor lang tid tager det typisk at sætte hele workflowet op fra bunden?
Følger du trinene i denne guide på et nyt, lille projekt, bør du regne med omkring 40-50 minutter i alt, hvoraf størstedelen går til at installere Docker og VS Code, hvis du ikke allerede har dem, samt den første containerbygning. På et eksisterende, større projekt kan det tage længere tid at skrive en devcontainer.json, der dækker alle reelle afhængigheder korrekt.
