Visual Studio Code er stadig den editor, flest udviklere åbner hver morgen. Ifølge Stack Overflows udviklerundersøgelse for 2026 bruger 75,9 procent af respondenterne værktøjet regelmæssigt, og Microsoft oplyser, at over 50 millioner udviklere logger ind i Visual Studio-familien hver måned (SecondTalent, 2026). Men “bare installer det” er sjældent nok. En ordentlig opsætning med de rigtige udvidelser, en fungerende Git-integration, en AI-assistent og korrekt debugging sparer timer hver eneste uge.
Denne guide går dig gennem 13 konkrete trin: fra download af den nyeste stabile version (1.132, udgivet 5. august 2026) til Dev Containers, Settings Sync og et komplet eksempelprojekt du kan teste med det samme. Vi dækker også fem faldgruber, otte fejlfindingsscenarier, en dedikeret sektion om telemetri og databeskyttelse, og en sikkerhedsopdatering, du ikke bør ignorere.
Guiden er skrevet, så du kan følge den lineært fra en tom maskine til et kørende projekt, men hvert trin står også for sig selv. Har du allerede editoren installeret, kan du springe direkte til afsnittet om Dev Containers, telemetri eller fejlfinding, alt efter hvad du mangler.
Hvorfor Visual Studio Code stadig dominerer i 2026
Konkurrencen fra Cursor, Zed og JetBrains AI Assistant har ikke rykket ved Visual Studio Codes position som standardværktøj. Tallene fra Stack Overflow-undersøgelsen for 2026 viser, at editoren “stadig er standarden”, som rapporten formulerer det, mens mange udviklere kører Cursor oven på den samme kodebase i stedet for at skifte helt væk. Det skyldes dels et marketplace med over 50.000 udvidelser, dels at Microsoft har presset flere AI-funktioner direkte ind i kernen af produktet gennem 2026.
Det er værd at skelne mellem to ting, når man taler om “Visual Studio Code”. Kildekoden ligger åben i microsoft/vscode-repositoriet under navnet “Code – OSS” og er fri for telemetri og Microsofts branding. Den version, de fleste henter fra code.visualstudio.com, er derimod en Microsoft-bygget udgave med ekstra branding, en Marketplace-integration og telemetri slået til som standard. Forskellen betyder ikke noget for hverdagsbrug, men den bliver relevant, når du senere i guiden skal tage stilling til, hvor mange data editoren sender hjem til Microsoft.
Juli og august 2026 bragte flere konkrete opdateringer. Version 1.127 gav agenter adgang til den indbyggede browser, så en AI-assistent kan åbne en side, læse konsolfejl og klikke sig gennem et flow uden en ekstern MCP-server. Version 1.128 tilføjede Copilot Vision, der lader dig sætte billeder og PDF-filer direkte ind i en chat. Version 1.131 introducerede indbygget offline diktering, og den nyeste stabile udgivelse, 1.132 fra 5. august, lagde side-chats, Markdown-diff og element-niveau feedback fra den integrerede browser oveni. En Insiders-build, 1.133, dateret 12. august, ligger allerede et skridt foran med endnu mere fleksible Claude-sessioner.
Det gør Visual Studio Code til et bevægeligt mål. Denne guide bruger derfor version 1.132 som reference, men trinene virker uændret på både ældre og nyere udgivelser.
Forudsætninger: dette skal du bruge, før du starter
Før du går i gang, skal maskinen leve op til nogle minimumskrav. Visual Studio Code er let sammenlignet med en fuld IDE, men enkelte funktioner (Dev Containers, store extensions, flere sprogservere samtidig) trækker mere.
| Krav | Minimum | Anbefalet |
|---|---|---|
| Operativsystem | Windows 10, macOS 12, Linux med glibc 2.28+ | Windows 11, macOS 14+, Ubuntu 22.04+ |
| RAM | 1 GB | 4 GB eller mere |
| Diskplads | 500 MB til selve editoren | 2 GB+ inklusive udvidelser og cache |
| Processor | 64-bit x64 eller ARM64 | Apple Silicon eller nyere x64 |
| Git | Version 2.30 eller nyere | Seneste stabile version |
| Node.js (valgfrit) | Kun nødvendigt til visse udvidelser | LTS-version, hvis du udvikler webapps |
Du behøver ikke en Microsoft-konto for at bruge editoren, men du får adgang til Settings Sync og GitHub Copilots gratis niveau, hvis du logger ind med en GitHub-konto. Har du allerede JetBrains AI Assistant eller Cursor opsat, kan du roligt køre Visual Studio Code side om side. Mange af trinene her genbruger den samme Git-konfiguration og de samme SSH-nøgler.
Trin 1-3: installation og første opstart
Trin 1: download og installer Visual Studio Code
Hent installationsfilen fra den officielle setup-dokumentation. På Windows kan du også installere via winget, på macOS via Homebrew, og på Linux via din distributions pakkehåndtering eller Snap.
# Windows (winget)
winget install -e --id Microsoft.VisualStudioCode
# macOS (Homebrew)
brew install --cask visual-studio-code
# Ubuntu / Debian
sudo apt update && sudo apt install -y wget gpg
wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > packages.microsoft.gpg
sudo install -D -o root -g root -m 644 packages.microsoft.gpg /usr/share/keyrings/
sudo apt install -y apt-transport-https
sudo apt update && sudo apt install -y codeEfter installationen kan du bekræfte versionen fra terminalen. Det er også den hurtigste måde at tjekke, om `code`-kommandoen er tilgængelig i din PATH.
$ code --version
1.132.0
a1b2c3d4e5f6789...
x64Trin 2: første opstart og grundlæggende indstillinger
Åbn Command Palette med Ctrl+Shift+P (macOS: Cmd+Shift+P) og søg efter “Preferences: Open User Settings (JSON)”. Her sætter du de indstillinger, der følger dig på tværs af projekter, i modsætning til workspace-specifikke indstillinger, som kun gælder én mappe.
{
"editor.fontSize": 14,
"editor.formatOnSave": true,
"editor.tabSize": 2,
"files.autoSave": "onFocusChange",
"workbench.colorTheme": "Default Dark Modern",
"terminal.integrated.defaultProfile.linux": "bash"
}Aktiver formatOnSave tidligt. Det tvinger dig til at rydde op i formateringen, før du overhovedet begynder at installere linter-udvidelser, og det sparer diskussioner i pull requests senere. Har du brug for bedre læsbarhed, findes der også indbyggede tilgængelighedsindstillinger under “Accessibility” i indstillingerne, herunder skærmlæser-optimeret tilstand og justerbar markørbredde. De fleste udviklere overser dem, fordi de ligger gemt væk fra de almindelige redigeringsindstillinger, men de er værd at kende, hvis du eller en kollega arbejder med et hjælpemiddel.
Trin 3: installer essentielle udvidelser fra Marketplace
Med over 50.000 udvidelser i markedspladsen er det let at drukne. Her er dem, der går igen i de fleste opsætninger uanset sprog, ifølge en gennemgang af de mest anvendte VS Code-udvidelser i 2026 (Visual Studio Marketplace).
Del dem gerne op i tre kategorier, når du planlægger en opsætning. Første kategori er kernefunktioner, alle bør have: Git-værktøjer, en formatter og en linter. Anden kategori er sprogspecifikke udvidelser, som kun giver mening, hvis du rent faktisk skriver Python, Go eller Rust. Tredje kategori er AI- og produktivitetsværktøjer, hvor valget i høj grad afhænger af budget og personlig smag. Start med kernekategorien, tilføj sprog-pakken til dit primære stack, og vent med resten til du oplever et konkret behov. Det er langt lettere at tilføje en udvidelse senere end at rydde op i tyve, du aldrig bruger.
| Udvidelse | Udgiver | Installationer | Pris |
|---|---|---|---|
| GitHub Copilot | GitHub | 15+ millioner | 10 USD/md (gratis for studerende) |
| GitLens | GitKraken | 8+ millioner | Gratis kerne, betalt Pro |
| Error Lens | Alexander | Millioner | Gratis |
| Prettier | Prettier | Millioner | Gratis |
| ESLint | Microsoft | Millioner | Gratis |
| Tailwind CSS IntelliSense | Tailwind Labs | Millioner | Gratis |
Installer dem hurtigt fra terminalen i stedet for at klikke dig igennem UI’et manuelt.
code --install-extension github.copilot
code --install-extension eamodio.gitlens
code --install-extension usernamehw.errorlens
code --install-extension esbenp.prettier-vscode
code --install-extension dbaeumer.vscode-eslintStandardiser opsætningen for hele teamet med extensions.json
Når et projekt har mere end én udvikler, er det spild af tid at forklare i et onboarding-dokument, hvilke udvidelser folk skal installere manuelt. Visual Studio Code løser det med en .vscode/extensions.json-fil, der lever i selve repositoriet. Åbner en kollega mappen for første gang, foreslår editoren automatisk at installere de anbefalede udvidelser.
{
"recommendations": [
"github.copilot",
"eamodio.gitlens",
"esbenp.prettier-vscode",
"dbaeumer.vscode-eslint",
"ms-vscode-remote.remote-containers"
]
}Kombiner filen med en delt .vscode/settings.json, der låser fælles regler som indrykning og formatering, mens personlige valg som tema og skrifttype forbliver i den enkelte udviklers globale indstillinger. Det er en lille investering, der typisk sparer et par timers frem-og-tilbage i de første uger på et nyt projekt, og det er en af de detaljer, erfarne teamledere ofte glemmer at nævne, når de sætter nye udviklere op.
Trin 4-6: Git, versionsstyring og AI-assistent
Trin 4: konfigurer Git og versionsstyring
Visual Studio Code har indbygget Git-support, men den kræver at Git selv er installeret og konfigureret med dit navn og din e-mail. Kildekontrol-panelet (Ctrl+Shift+G) viser ændringer, staging og commit-historik uden at du åbner en terminal.
git config --global user.name "Dit Navn"
git config --global user.email "[email protected]"
git config --global init.defaultBranch mainGitLens bygger videre på dette og viser hvem der sidst ændrede en linje kode direkte inline, hvilket er nyttigt, når flere teammedlemmer arbejder i samme fil.
Trin 5: opsæt en AI-kodeassistent
GitHub Copilot forbliver den mest installerede AI-udvidelse i markedspladsen med et gratis niveau for studerende og en betalt plan fra 10 USD om måneden for resten. Log ind med din GitHub-konto via kontoikonet nederst til venstre, og godkend adgangen i browseren, der åbner automatisk. Foretrækker du en anden model, kan du vælge mellem Anthropic-drevne og Copilot-drevne modeller direkte i chat-panelet i VS Code. Modeller under “Anthropic” trækker på din egen API-nøgle, mens modeller under “Copilot” bruger dit Copilot-abonnement, så vælg ud fra hvor du allerede har budget afsat.
Har du allerede en Cursor- eller Claude Code-opsætning, behøver du ikke droppe den. Mange udviklere kører flere assistenter parallelt og skifter afhængigt af opgaven, som vi også har dækket i vores gennemgang af JetBrains AI Assistant.
Prisstrukturen har ændret sig markant i 2026. Copilot gik fra faste “Premium Request”-kvoter til et token-baseret system kaldet GitHub AI Credits, hvor hver krone forbrug afspejler den model, du rent faktisk bruger. En simpel autofuldførelse koster stort set ingenting, mens en agent, der kører gennem hele filer med en avanceret model, kan bruge et helt månedskvote på få timer. Hold øje med forbrugsmåleren i statuslinjen, hvis du arbejder med agent-tilstand på en gratis eller billig plan, så du ikke bliver overrasket af en regning midt i måneden.
Trin 6: aktiver Settings Sync på tværs af enheder
Settings Sync deler indstillinger, tastaturgenveje, snippets, opgaver, UI-tilstand, udvidelser og profiler mellem alle dine maskiner, ifølge den officielle dokumentation. Åbn Command Palette og vælg “Backup and Sync Settings…” fra tandhjuls-menuen eller kontomenuen i sidebjælken. Log ind med enten en Microsoft- eller GitHub-konto, og vælg hvilke kategorier du vil synkronisere.
Funktionen er nu tæt koblet til profiler, så du kan have én profil til Python-arbejde og en anden til frontend uden at de blander indstillinger sammen. Skifter du fra en bærbar til en stationær maskine midt i en arbejdsdag, betyder det i praksis, at dine tastaturgenveje, dit tema og de samme udvidelser er klar, allerede før du har åbnet det første projekt. Det er en lille detalje, men den sparer den irriterende “hvorfor virker min genvej ikke her”-fornemmelse, som ellers rammer, hver gang man skifter maskine.
Trin 7-9: Dev Containers, debugging og terminal
Trin 7: Dev Containers og Remote Development
Remote Development-pakken samler tre udvidelser: Dev Containers, Remote SSH og Remote WSL. Dev Containers lader dig udvikle inde i en containeriseret opsætning, så hele teamet kører identiske værktøjer og afhængigheder uanset hvad der ligger på deres egen maskine (Microsofts Dev Containers-dokumentation). Opret en .devcontainer/devcontainer.json i roden af projektet.
{
"name": "node-dev-container",
"image": "mcr.microsoft.com/devcontainers/javascript-node:20",
"features": {
"ghcr.io/devcontainers/features/git:1": {}
},
"customizations": {
"vscode": {
"extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
}
},
"postCreateCommand": "npm install"
}Åbn projektet, og vælg “Reopen in Container” fra Command Palette. Første opstart tager typisk et par minutter, mens billedet bygges. Efterfølgende åbninger genbruger cachen og starter på sekunder. På Windows kræver Dev Containers, at Docker Desktop kører oven på WSL2, ikke den ældre Hyper-V-baserede motor, da WSL2-integrationen giver markant hurtigere fildeling mellem Windows og containeren. Er din editor mærkbart langsom, når du redigerer filer inde i en container på Windows, er det ofte tegn på, at den forkerte motor er valgt i Docker Desktops indstillinger.
Trin 8: debugging og launch.json
Debug-panelet (Ctrl+Shift+D) kræver en launch.json, der fortæller editoren hvordan projektet skal startes med breakpoints aktive. Vælg “create a launch.json file” og tilpas konfigurationen til dit sprog.
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Kør server.js",
"program": "${workspaceFolder}/server.js",
"skipFiles": ["/**"]
}
]
} Sæt et breakpoint ved at klikke i venstre margen på en linje kode, tryk F5, og eksekveringen stopper der. Variabelruden til venstre viser den aktuelle værdi af alle variable i scope, uden at du behøver indsætte en eneste console.log.
Trin 9: tilpas terminal og tastaturgenveje
Den integrerede terminal (Ctrl+`) understøtter flere paneler side om side. Du kan for eksempel køre en dev-server i det ene og tests i det andet uden at skifte vindue. Højreklik på et terminalpanel for at splitte det, eller brug “Terminal: Create New Terminal” flere gange for at stable dem lodret. Kombinerer du det med compound-tasks i tasks.json, kan du starte hele udviklingsmiljøet, database, backend og frontend, med én kommando, i stedet for at åbne tre separate terminalvinduer manuelt hver morgen. Genvejstasterne herunder dækker de handlinger, der bruges oftest ifølge gennemgange af produktivitet i VS Code.
| Handling | Windows/Linux | macOS |
|---|---|---|
| Åbn fil hurtigt | Ctrl+P | Cmd+P |
| Command Palette | Ctrl+Shift+P | Cmd+Shift+P |
| Åbn terminal | Ctrl+` | Cmd+` |
| Kildekontrol | Ctrl+Shift+G | Cmd+Shift+G |
| Split editor | Ctrl+\ | Cmd+\ |
| Gå til definition | F12 | F12 |
Trin 10-13: produktivitet, workspaces og VS Code for Web
Trin 10: opret et workspace til flere mapper
Arbejder du på et projekt bestående af en frontend og en backend i to separate mapper, samler et multi-root workspace dem i én editor-visning. Gem opsætningen som en .code-workspace-fil, så resten af teamet kan åbne den samme struktur med ét klik. Workspace Trust gælder pr. mappe i et multi-root workspace, så du kan for eksempel stole på din egen frontend-kode fuldt ud, mens en tredjeparts-submodul stadig åbnes i begrænset tilstand, indtil du aktivt godkender den.
Trin 11: vælg og tilpas et tema
Temaet påvirker ikke kun udseendet, men også hvor hurtigt du opdager syntaksfejl. “Default Dark Modern” er standard i 2026-udgaverne, men prøv gerne “GitHub Dark” eller “One Dark Pro”, hvis du kommer fra en anden editor og vil genkende farverne. Har du brug for højere kontrast, findes der indbyggede “High Contrast”-temaer under Preferences, og de virker sammen med et separat ikontema, så filtyper stadig er lette at skelne fra hinanden i sidepanelet.
Trin 12: brug VS Code for Web til hurtige rettelser
På vscode.dev kører hele editoren i browseren uden installation. Den er begrænset af browserens sandkasse og kan derfor ikke køre lokale build-værktøjer eller native udvidelser, men den er ideel til hurtige rettelser i et GitHub-repository fra en maskine, du ikke selv ejer. Trykker du på punktum-tasten på et hvilket som helst GitHub-repository, åbner det automatisk i samme browserbaserede editor via github.dev, hvilket er den hurtigste vej fra en pull request til en rettelse, hvis du blot skal justere en enkelt linje.
Trin 13: hold editoren opdateret
Visual Studio Code opdaterer sig selv som standard, men i virksomhedsmiljøer med automatiske opdateringer slået fra bør du tjekke den officielle changelog månedligt. Det er særligt vigtigt efter en sikkerhedsrettelse, som vi kommer tilbage til nedenfor. IT-afdelinger, der styrer opdateringer centralt via gruppepolitikker, bør sætte en fast rutine op for at rulle sikkerhedsrettelser ud inden for få dage, i stedet for at vente på den næste planlagte softwareopdatering.
Komplet eksempelprojekt: fra tom mappe til kørende debugger
Teori er godt, men et fungerende eksempel viser om opsætningen faktisk hænger sammen. Saml alle trinene ovenfor i et lille, fungerende projekt. Opret en mappe, initialiser Git, og tilføj en minimal Node.js-server, du kan debugge direkte. Følg trinene i rækkefølge, og du bør have et kørende, debugbart projekt på under ti minutter, selv med Dev Containers inkluderet.
mkdir mit-vscode-projekt && cd mit-vscode-projekt
git init
npm init -y
code .Opret server.js med et simpelt HTTP-endpoint:
const http = require("http");
const server = http.createServer((req, res) => {
res.writeHead(200, { "Content-Type": "text/plain" });
res.end("Serveren kører fra VS Code");
});
server.listen(3000, () => {
console.log("Lytter på http://localhost:3000");
});Tilføj .devcontainer/devcontainer.json og .vscode/launch.json fra trin 7 og 8, og genåbn projektet i containeren. Tryk F5, og terminalen bør vise:
Lytter på http://localhost:3000
Debugger attached.Sæt et breakpoint på linjen med res.end, åbn localhost:3000 i browseren, og bekræft at eksekveringen stopper i editoren. Lykkes det, har du nu en fuld opsætning med versionsstyring, en reproducerbar container, debugging og en AI-assistent klar til at foreslå kode, mens du arbejder videre.
Tilføj til sidst en simpel test og genbrug tasks.json fra afsnittet om avancerede tips, så du kan bygge og teste projektet med samme genvej hver gang.
// test.js
const assert = require("assert");
function svarKode() {
return 200;
}
assert.strictEqual(svarKode(), 200);
console.log("Test bestået");Kør testen fra terminalen med node test.js, eller bind den til Command Palette via “Tasks: Run Task”, så du kan trigge den med et enkelt tastetryk uden at forlade editoren. Kombinerer du dette med GitLens’ commit-historik, kan du hurtigt se præcis hvilken ændring der senest rørte ved en fil, hvis testen pludselig fejler.
5 almindelige faldgruber, du skal undgå
De fleste af disse fejl koster ikke noget alvorligt, men de spiser tid og skaber unødvendig frustration i de første uger med en ny opsætning. Gennemgå listen, før du ruller din konfiguration ud til et helt team.
- At installere for mange udvidelser på én gang. Hver aktiv udvidelse bruger RAM og kan bremse opstarten. Deaktiver dem, du ikke bruger dagligt, i stedet for at afinstallere, så du hurtigt kan slå dem til igen. En tommelfingerregel er at gennemgå listen over aktive udvidelser hver tredje måned og fjerne dem, der ikke er brugt siden sidst.
- At glemme workspace-specifikke indstillinger. Indstillinger sat i
.vscode/settings.jsonoverskriver dine globale valg og kan skabe forvirring, hvis du ikke ved, de findes. Kommenter filen, så nye teammedlemmer forstår hvorfor et bestemt valg er låst på projektniveau. - At køre Dev Containers uden Docker installeret. Editoren fejler stille, hvis Docker Desktop eller en kompatibel motor ikke kører i baggrunden. Tjek altid Docker-status først, før du antager at selve devcontainer.json-filen er fejlbehæftet.
- At ignorere Settings Sync-konflikter. Synkroniserer du fra flere maskiner uden at slå automatisk sammenlægning til, kan du ende med at overskrive en nyere konfiguration med en ældre. Tjek konflikt-loggen manuelt, hvis du har arbejdet offline på to maskiner samtidig.
- At give AI-assistenten adgang til hemmeligheder. Chat-konteksten kan inkludere hele filer. Hold API-nøgler og adgangskoder i
.env-filer, der er tilføjet til.gitignore, så de aldrig havner i en prompt ved et uheld. Overvej desuden at ekskludere hele mapper med testdata eller kundedata fra det, AI-assistenten får adgang til at læse.
Fejlfinding: 8 typiske problemer og løsninger
Når noget går galt, er det sjældent editoren selv, der er skyld i det. Langt de fleste problemer skyldes en udvidelse, der ikke er opdateret, en cache der er blevet korrupt, eller en sti der peger det forkerte sted hen. Gennemgå tabellen nedenfor, før du geninstallerer hele editoren fra bunden, hvilket sjældent løser noget, du ikke også kunne have fikset på to minutter.
| Problem | Sandsynlig årsag | Løsning |
|---|---|---|
| “code” kommandoen findes ikke i terminalen | PATH er ikke opdateret | Kør “Shell Command: Install ‘code’ command in PATH” fra Command Palette |
| Udvidelser loader ikke efter opdatering | Korrupt cache | Genstart med “Developer: Reload Window” eller ryd cache-mappen |
| Dev Container starter ikke | Docker-motoren kører ikke | Start Docker Desktop eller Podman, og prøv “Rebuild Container” igen |
| Copilot foreslår intet | Ikke logget ind eller abonnement udløbet | Tjek statusikonet nederst til højre og log ind igen via GitHub |
| Settings Sync synkroniserer ikke | Login-token er udløbet | Log ud og ind igen fra kontomenuen i sidebjælken |
| Debugger rammer ikke breakpoints | Forkert sourcemap eller forkert program-sti i launch.json | Bekræft “program”-stien og aktiver sourcemaps i din build |
| Editoren er langsom ved opstart | For mange udvidelser aktive i alle workspaces | Brug “Extensions: Show Running Extensions” og deaktiver de tungeste |
| Terminalen bruger forkert shell | Standardprofilen peger på den forkerte shell | Sæt “terminal.integrated.defaultProfile” til den ønskede shell i settings.json |
Løser ingen af løsningerne ovenfor problemet, er logfilerne dit næste stop. Åbn Command Palette og kør “Developer: Open Log File…” for at se editorens egne fejlmeddelelser, eller “Developer: Toggle Developer Tools” for at få adgang til browser-konsollen bag brugerfladen. Langt de fleste sager, der ender som bug-rapporter på GitHub, kunne være løst hurtigere, hvis brugeren havde kigget her først, i stedet for at gætte sig frem.
Avancerede tips til erfarne udviklere
Når de grundlæggende trin sidder fast, er der en række finjusteringer, der først bliver relevante, når du bruger editoren dagligt. Profiler er den mest undervurderede funktion: opret en separat profil per sprog eller projekttype, så en tung Python-opsætning med linters og debuggere ikke bremser et lille Bash-script, du bare skal redigere hurtigt.
Brug tasks.json til at kæde flere kommandoer sammen, så du kan bygge og teste med én genvej i stedet for at skifte til terminalen hver gang.
{
"version": "2.0.0",
"tasks": [
{
"label": "build og test",
"type": "shell",
"command": "npm run build && npm test",
"group": { "kind": "test", "isDefault": true }
}
]
}Aktiver også de sandboxede terminal-kommandoer, der kom med version 1.127 og 1.130. De begrænser hvad en AI-agent kan røre ved filsystem og netværk, uden at du skal godkende hver enkelt kommando manuelt, hvilket er relevant hvis du lader Copilot eller en anden agent køre længere opgaver uden opsyn. Kombiner det med Copilot Vision fra version 1.128, hvor du kan trække et skærmbillede af en fejl direkte ind i chatten i stedet for at beskrive den med ord.
Ramte du en fejl, der først dukkede op efter en opdatering, kan “Help: Start Extension Bisect” hjælpe dig med at finde synderen. Funktionen deaktiverer halvdelen af dine udvidelser ad gangen og beder dig bekræfte, om fejlen forsvinder, indtil du sidder tilbage med den ene udvidelse, der forårsager problemet. Det er langt hurtigere end at deaktivere udvidelser én for én manuelt, især hvis du kører tyve eller flere på samme maskine.
Overvej også at eksportere din profil, når opsætningen sidder, som du vil have den. Fra profil-menuen kan du gemme indstillinger, udvidelser og genveje som en delbar fil, som kollegaer kan importere direkte i stedet for at følge en lang installationsguide. Det er den samme mekanisme, som Settings Sync bruger internt, blot uden at kræve en fælles konto.
Visual Studio Code vs. alternativerne: hvornår skal du vælge noget andet?
Visual Studio Code er ikke det rette valg til alle. Her er en kort sammenligning, du kan bruge til at vurdere, om et af alternativerne passer bedre til dit team. Kriterierne er de samme, uanset om du sammenligner for dig selv eller for et helt team: hvor meget vægt lægger I på et bredt udvidelsesøkosystem versus dyb sprogforståelse, og hvor afhængige er I allerede af en bestemt AI-assistent.
| Editor | Bedst til | Pris | Licens |
|---|---|---|---|
| Visual Studio Code | Alsidighed, størst udvidelsesøkosystem | Gratis | MIT (kerne open source) |
| Cursor | AI-først kodning med agent-fokus | Fra gratis til abonnement | Proprietær |
| JetBrains-IDE’er + AI Assistant | Store, sprogspecifikke projekter (Java, Kotlin, .NET) | 10-30 USD/md individuel | Proprietær |
| Zed | Rå ydelse og lav ressourceforbrug | Gratis | Open source |
Vælger du en stor Java- eller .NET-kodebase, er en JetBrains-IDE ofte stadig bedre til refaktorering på tværs af filer, hvilket vi har gennemgået i vores JetBrains AI Assistant-opsætning. Kører du derimod på tværs af mange sprog og rammer, vinder Visual Studio Code på fleksibilitet og udvidelsesudvalg.
For et team er den samlede omkostning sjældent kun licensprisen. En gratis editor med et dyrt AI-abonnement kan hurtigt koste mere end en betalt IDE med en billigere assistent inkluderet, afhængigt af hvor meget I bruger agent-funktioner. Regn på det ud fra faktisk forbrug, ikke listepris, før du beslutter dig for en standard på tværs af et helt team. Et lille team med to eller tre udviklere mærker sjældent forskellen, men på tyve eller flere licenser kan valget mellem platforme løbe op i flere tusinde kroner om året.
Sikkerhed og opdateringer: CVE-2026-47285
Den 11. august 2026 offentliggjorde Microsoft en sikkerhedsrådgivning for CVE-2026-47285, en sårbarhed der kan udnyttes til command injection over netværket. Alle versioner fra 1.0.0 til og med 1.132.0 er berørt, og 1.132.1 er den første rettede udgivelse. Kører du en ældre version med automatiske opdateringer slået fra, bør du opdatere med det samme.
Det er ikke den første sårbarhed i editoren, og det bliver formentlig heller ikke den sidste. Fordi Visual Studio Code kører med adgang til dit filsystem og typisk er koblet til Git-legitimationsoplysninger, SSH-nøgler og AI-udvidelser med adgang til kildekode, er en enkelt uopdateret installation potentielt en indgang til meget mere end selve editoren. Hvis din organisation styrer flere hundrede udviklermaskiner, er det værd at sætte en automatiseret proces op, der tjekker versionsnummeret på tværs af flåden i stedet for at stole på, at hver enkelt udvikler opdaterer manuelt.
For et lille dansk teknologiteam handler det ofte om at have én person med ansvar for at følge changelog og sikkerhedsrådgivninger, og om at have en fast dag i måneden, hvor alle opdaterer samlet. For et større team giver det mening at koble opdateringstjek til det samme system, I allerede bruger til at overvåge afhængigheder i jeres kodebaser, så en ny CVE i editoren dukker op i den samme kanal som en sårbar npm-pakke ville gøre.
Tjek din nuværende version og opdater manuelt, hvis nødvendigt:
# Tjek version
code --version
# Windows: opdater via winget
winget upgrade Microsoft.VisualStudioCode
# macOS: opdater via Homebrew
brew upgrade --cask visual-studio-codeSikkerhedsopdateringer er en god anledning til at gennemgå hvilke udvidelser du reelt bruger. Fjern dem, du ikke har åbnet i flere måneder, for at reducere den samlede angrebsflade.
Workspace Trust er en anden funktion, der er let at overse. Åbner du en mappe, du har hentet fra en ukendt kilde, spørger editoren, om du vil åbne den i en begrænset tilstand, hvor opgaver, debugging og visse udvidelser er deaktiveret, indtil du eksplicit stoler på mappen. Slå ikke funktionen fra globalt, selv hvis den føles i vejen. Den er den letteste beskyttelse, du har mod et repository med et ondsindet tasks.json, der forsøger at eksekvere kode, i det øjeblik du åbner projektet.
Databeskyttelse: sådan minimerer du telemetri i VS Code
For danske og nordiske virksomheder, der arbejder under GDPR, er telemetri sjældent et rent teknisk spørgsmål. Den Microsoft-byggede udgave af Visual Studio Code sender som standard brugs- og fejldata til Microsoft, mens den åbne “Code – OSS”-kerne ikke gør. De fleste organisationer kan nøjes med at skrue ned for telemetrien i stedet for at skifte hele byggekæden ud, og det gør du direkte fra indstillingerne.
{
"telemetry.telemetryLevel": "off",
"workbench.enableExperiments": false,
"extensions.autoCheckUpdates": true,
"update.showReleaseNotes": false
}Bemærk at telemetry.telemetryLevel kun styrer editorens egen indsamling. Tredjepartsudvidelser, herunder AI-assistenter, har typisk deres egne indstillinger for datadeling, og de skal deaktiveres separat i den enkelte udvidelses konfiguration. Gennemgå især AI-relaterede udvidelser, hvis din organisation har en politik om, at kildekode ikke må forlade virksomhedens netværk. Kør en hurtig audit ved at åbne “Extensions: Show Installed Extensions” og tjekke hver enkelt udvidelses privatlivsside i Marketplace, før du ruller opsætningen ud til et helt team.
Ofte stillede spørgsmål
Er Visual Studio Code gratis?
Ja. Selve editoren er gratis, og kernen er open source under MIT-licensen via microsoft/vscode-repositoriet. Betalte omkostninger kommer udelukkende fra tredjepartsudvidelser som GitHub Copilot. Store organisationer, der har brug for support-aftaler, licensstyring eller compliance-dokumentation, kan tegne det gennem Microsofts virksomhedsaftaler, men det er et tillæg til en i øvrigt gratis editor, ikke en forudsætning for at bruge den.
Hvilken version af Visual Studio Code bør jeg bruge?
Brug den nyeste stabile version, i skrivende stund 1.132 fra 5. august 2026. Undgå Insiders-builds som 1.133 til produktionsarbejde, medmindre du aktivt vil teste kommende funktioner og rapportere fejl.
Kan jeg bruge GitHub Copilot gratis?
Studerende og verificerede undervisere kan få adgang gratis. Øvrige brugere betaler fra 10 USD om måneden for Copilot Pro, som vi har dækket i detaljer i vores GitHub Copilot-opsætningsguide.
Hvad er forskellen på Dev Containers og Remote SSH?
Dev Containers kører dit projekt inde i en lokal eller fjern container med et defineret sæt afhængigheder. Remote SSH forbinder i stedet direkte til en fjernserver eller virtuel maskine, uden nødvendigvis at bruge en container. Begge dele indgår i Remote Development-pakken. Vælg Dev Containers, når du vil have et reproducerbart, delt miljø på tværs af et team, og vælg Remote SSH, når du blot skal redigere filer på en server, du allerede har adgang til, uden at bygge et container-image.
Hvorfor er min editor langsom efter jeg installerede flere udvidelser?
Hver aktiv udvidelse kører i egen proces og bruger RAM og CPU. Brug “Extensions: Show Running Extensions” fra Command Palette til at se, hvilke der belaster mest, og deaktiver dem du ikke bruger i det aktuelle workspace.
Kan jeg synkronisere min opsætning mellem en arbejds-pc og en privat maskine?
Ja, gennem Settings Sync. Log ind med samme konto på begge maskiner, og vælg hvilke kategorier (indstillinger, udvidelser, genveje) du vil dele. Vær opmærksom på virksomhedspolitikker, hvis du synkroniserer arbejdsrelaterede udvidelser til en privat konto. Flere organisationer kræver, at arbejdsrelaterede profiler kun synkroniseres via en firmastyret konto, netop for at undgå at kildekode-relaterede udvidelser og indstillinger lander på private enheder uden for IT-afdelingens kontrol.
Er Visual Studio Code sikkert at bruge til fortrolig kode?
Editoren selv er sikker, men tredjepartsudvidelser og AI-chatfunktioner kan sende kodekontekst til eksterne servere. Gennemgå udvidelsernes privatlivspolitik, og hold følsomme filer ude af mapper, du deler med AI-assistenter, hvis din organisation kræver det.
Kan jeg flytte min opsætning fra en anden editor, for eksempel Sublime Text eller en JetBrains-IDE?
Ja, men forvent ikke en direkte import af alt. Visual Studio Code kan importere farvetemaer og enkelte genveje fra flere editorer via dedikerede migrations-udvidelser, men projektfiler som JetBrains’ .idea-mapper eller Sublimes projektfiler skal du selv genskabe med .vscode/settings.json og launch.json. Det tager typisk en halv til en hel arbejdsdag for et mellemstort projekt, afhængigt af hvor mange kørselskonfigurationer I har.
Følger du trinene i denne guide i rækkefølge, ender du med en opsætning, der dækker det meste af en normal arbejdsdag: installation, Git, en AI-assistent, en reproducerbar container, debugging og en telemetri-konfiguration, du selv har taget stilling til. Gem gerne dine settings.json, extensions.json og devcontainer.json i et separat “dotfiles”-repository, så du kan genskabe hele opsætningen på en ny maskine på få minutter i stedet for at gennemgå denne guide forfra.
