GitHub gjorde sit nye Copilot SDK generelt tilgængeligt den 2. juni 2026, og det ændrer hvordan udviklere kan bruge AI-agenten. Pakken giver direkte, programmatisk adgang til den samme agent-runtime, der driver Copilot i Visual Studio Code. I stedet for kun at bruge Copilot som en chatrude i editoren, kan du nu bygge agenten ind i din egen CLI, et internt devops-værktøj eller en Slack-bot, og selv bestemme hvilke filer den rører og hvornår den beder om lov.
Denne guide tager dig gennem 14 konkrete trin: fra installation og autentificering til brugerdefinerede værktøjer, Model Context Protocol-forbindelser, streaming og multi-turn sessioner. Undervejs bygger vi et komplet eksempelprojekt, en kommandolinje-agent der reviewer kode automatisk og foreslår rettelser. Koden er skrevet i TypeScript, men du får installationskommandoer til Python, Go, .NET, Rust og Java undervejs, så du kan vælge det sprog dit team allerede arbejder i. Sæt omkring 90 minutter af, hvis du vil følge med fra bund til et færdigt, kørende projekt.
Guiden er skrevet, så du kan springe direkte til det trin, du mangler, hvis du allerede har et projekt kørende. Har du aldrig arbejdet med agent-SDK’er før, anbefaler vi at følge trinene i rækkefølge, fordi hvert trin bygger videre på klienten og sessionen fra det forrige. Mod slutningen samler vi alt i ét sammenhængende eksempel, så du kan kopiere hele filen og tilpasse den til dit eget repository med det samme.
Gå ikke glip af nye tech-historier på Google
Tilføj Shattered én gang i Google-appen, så dukker vores artikler op i dine forslag.
Hvad er GitHub Copilot SDK?
GitHub Copilot SDK er en samling af biblioteker, der giver udviklere direkte adgang til Copilots agent-motor uden om browseren eller editoren. GitHub meldte SDK’et generelt tilgængeligt den 2. juni 2026, efter en periode med lukket preview. Det betyder at pakken nu har en stabil API, som virksomheder kan bygge produktionskode på, i modsætning til tidligere forsøgsversioner, hvor grænsefladen kunne ændre sig fra uge til uge.
Kernen i SDK’et er den samme agent-runtime, der ligger bag Copilot Chat og Copilot-agenten i VS Code. Det giver adgang til fire centrale funktioner. Først agent-planlægning, hvor modellen selv bryder en opgave ned i delopgaver. Dernæst værktøjskald (tool invocation), hvor agenten selv vælger og kører funktioner du har defineret. Tredje er filredigering, hvor agenten kan læse og ændre filer i et projekt. Fjerde er streaming af svar samt understøttelse af sessioner med flere beskeder, det GitHub kalder multi-turn.
Det afgørende skift er, at du ikke længere er bundet til at bruge Copilot inde i en editor. Du kan sætte den samme agent ind i et internt CI/CD-værktøj, en kundevendt chatbot eller et script der kører om natten og rydder op i gammel kode. GitHub beskriver i sin egen lanceringsmeddelelse, at SDK’et giver direkte, programmatisk adgang til den samme agent-runtime, der ligger bag GitHub Copilot, og at det er bygget til produktion fra dag ét frem for kun eksperimenter.
SDK’et lader dig også overskrive indbyggede værktøjer som grep og edit_file med dine egne implementeringer. Det er nyttigt, hvis din organisation for eksempel har en særlig fillåsnings-politik, eller hvis du vil logge hver eneste filændring til et separat revisionsspor, før den rammer disken. Du kan samtidig tilføje helt nye værktøjer, som agenten selv vælger at bruge, når opgaven kræver det.
Endelig understøtter SDK’et forbindelse til Model Context Protocol-servere (MCP), som vi dækker i detaljer senere i guiden. Det betyder, at agenten kan hente kontekst fra eksterne systemer, for eksempel en database, et ticketsystem eller en intern dokumentationsplatform, uden at du selv skal bygge hele integrationslaget fra bunden. GitHub har offentliggjort en kom-i-gang-guide, en kogebog med eksempler og dokumentation om autentificering sammen med lanceringen, hvilket gør det til et godt tidspunkt at begynde at eksperimentere, selv hvis din organisation endnu ikke har en konkret use case klar.
Det er værd at skelne mellem SDK’et og en rå model-API. Hvis du bare kalder en sprogmodel direkte, skal du selv bygge logikken for planlægning, værktøjskald, filhåndtering og sessionsstyring fra bunden, hvilket typisk tager et team flere uger at få stabilt. Copilot SDK leverer den infrastruktur færdig, testet og produktionsklar, så dit eget arbejde i stedet handler om at definere, hvilke værktøjer agenten skal have adgang til, og hvilke regler den skal følge i din konkrete kontekst.
Hvorfor bygge din egen AI-kodeagent?
Interessen for AI-agenter i softwareudvikling er vokset markant det seneste år. Ifølge Stack Overflows udviklerundersøgelse for 2025 svarede 84 procent af de adspurgte, at de bruger eller planlægger at bruge AI-værktøjer i deres udviklingsproces, op fra 76 procent året før. Samme undersøgelse viste, at 31 procent allerede bruger AI-agenter specifikt, mens 38 procent svarede, at de ikke planlægger at gøre det foreløbig.
Blandt de udviklere, der bruger et AI-værktøj ud af boksen, svarede 67,9 procent, at det er GitHub Copilot de griber til. Det gør Copilot til det mest udbredte valg i markedet, og dermed også det mest sandsynlige fundament at bygge videre på, hvis du vil undgå at genopfinde model-integration, autentificering og værktøjskald fra bunden selv.
Tallene peger dog også på en reel udfordring. 69 procent af de udviklere, der har brugt AI-agenter på arbejdet, sagde at værktøjerne øgede deres produktivitet. Men kun 29 procent svarede, at de stoler på, at AI-outputtet er korrekt, et fald fra 40 procent året før. Den kombination, høj oplevet produktivitet og faldende tillid til nøjagtigheden, er præcis den type problem du kan designe dig ud af, når du bygger din egen agent frem for at bruge en færdig chatboks uden indsigt i, hvad der sker bag kulisserne.
Når du selv styrer agentens værktøjer og tilladelser via SDK’et, kan du for eksempel kræve menneskelig godkendelse før enhver push til hovedgrenen, begrænse agenten til kun at læse i bestemte mapper, eller logge hver eneste beslutning agenten tager, så et team senere kan gennemgå den. Det er den slags kontrol, en generisk chatintegration i editoren sjældent giver dig adgang til.
Trenden rækker også ud over GitHub selv. Ifølge en opsamling fra Vibehackers om udviklingen i AI-kodeværktøjer lancerede Cursor i starten af 2026 funktionen Automations, agenter der kører i skyen og trigges af hændelser fra Slack, Linear, GitHub og PagerDuty. Det viser, at hele branchen bevæger sig mod agenter der er indlejret i eksisterende workflows, frem for isolerede chatvinduer man selv skal huske at åbne. At bygge med Copilot SDK er derfor ikke et sidespor, men en del af en bredere bevægelse i udviklerværktøjer.
Der er også en praktisk årsag til at vælge SDK-vejen: mange teams har allerede interne værktøjer, dashboards og CI-pipelines. At integrere en agent direkte i de værktøjer, frem for at bede udviklere om at skifte til endnu en editor-udvidelse, reducerer friktionen markant og gør det lettere at måle den faktiske effekt på leveringstid og fejlrate.
Omkostninger og skalering: hvad du skal budgettere med
Før du sætter en agent i produktion, er det værd at tænke over, hvordan forbruget skalerer med antallet af brugere. En agent, der kører en enkelt kodegennemgang om dagen for ét team, opfører sig helt anderledes end en agent, der er koblet til hver eneste pull request i en organisation med hundredvis af udviklere. Jo flere automatiske triggere du bygger ind, jo vigtigere bliver det at have styr på, hvor mange sessioner der oprettes, og hvor mange værktøjskald hver session typisk bruger.
En praktisk tilgang er at starte i det små: kør agenten manuelt på udvalgte repositories i et par uger, og mål hvor mange værktøjskald en typisk opgave kræver. Brug de tal til at sætte realistiske grænser, før du kobler agenten til en automatisk trigger som en webhook eller en CI-pipeline. Det er langt billigere at opdage, at en opgave kræver 40 værktøjskald i stedet for de forventede 10, mens du stadig tester manuelt, end efter agenten kører ubemandet på tværs af hele organisationen. Skriv tallene ned i et simpelt regneark i starten, selv hvis det føles unødvendigt grundigt, for de bliver dit eneste konkrete grundlag, når du senere skal forsvare budgettet for et større rulleud til resten af organisationen.
Det er også værd at overveje, hvordan flere teams kan dele den samme grundinfrastruktur uden at dele de samme risici. Et marketingteam, der bruger en agent til at generere udkast til dokumentation, har brug for et helt andet sæt tilladelser end et platformteam, der lader agenten røre ved deploy-pipelines. Hold derfor klienter, værktøjer og tilladelser adskilt per use case, selv når de kører oven på samme underliggende abonnement, så en fejl i det ene projekt ikke automatisk giver agenten adgang til det andet.
Skalering handler også om organisation, ikke kun teknik. Udpeg ét team som ejer af agentens værktøjer og tilladelser, så ændringer går gennem en fast proces i stedet for at blive tilføjet ad hoc af forskellige udviklere. Det gør det markant lettere at svare på spørgsmål som “hvilke systemer kan agenten egentlig tilgå” og “hvem godkendte det her værktøj”, hvilket bliver stadig vigtigere, jo flere teams der begynder at bruge den samme agent-infrastruktur.
Forudsætninger: dette skal du bruge
Før du går i gang, skal du sikre dig at følgende er på plads. Guiden bruger TypeScript som primært sprog, men tabellen nedenfor viser alternativerne, hvis dit team foretrækker et andet sprog til agenten.
| Komponent | Version/krav | Bemærkning |
|---|---|---|
| GitHub-konto | Aktivt Copilot-abonnement | Individual, Business eller Enterprise |
| Node.js | 20 LTS eller nyere | Bruges til npm install @github/copilot-sdk |
| Python | 3.10 eller nyere | Alternativ, bruges med pip install github-copilot-sdk |
| Go | 1.22 eller nyere | Alternativ, bruges med go get github.com/github/copilot-sdk |
| .NET SDK | .NET 8 eller nyere | Alternativ, bruges med dotnet add package GitHub.Copilot.SDK |
| Rust | Seneste stabile version via rustup | Alternativ, bruges med cargo add github-copilot-sdk |
| Git | 2.40 eller nyere | Versionsstyring af dit projekt |
| Terminal | macOS, Linux eller WSL2 | Kommandoerne i denne guide er testet i et Unix-lignende miljø |
Du behøver ikke installere alle sprogene på én gang. Vælg det, dit team allerede bruger til interne værktøjer, og spring resten over for nu. Hvis du er i tvivl, er Node.js det hurtigste at komme i gang med, fordi størstedelen af de offentlige kodeeksempler fra GitHub tager udgangspunkt i TypeScript. Du skal desuden bruge en personal access token med Copilot-rettigheder, eller adgang til at logge ind interaktivt via GitHubs eget CLI-værktøj, før du kan autentificere SDK’et. Hvis din organisation styrer adgang centralt gennem en enterprise-konto, kan det være en god idé at tjekke med din platform- eller sikkerhedsafdeling, om der allerede findes en godkendt proces for at udstede tokens til interne værktøjer, i stedet for at hver udvikler genererer sin egen token ad hoc.
Copilot SDK vs. Copilot CLI vs. Copilot i IDE’en
GitHub tilbyder nu tre forskellige måder at bruge Copilot-agenten på, og det er let at blande dem sammen. Copilot i IDE’en er den velkendte udgave, hvor du chatter med agenten direkte i VS Code, JetBrains-editorer eller Visual Studio. Copilot CLI er en terminal-native udgave af agenten, som blev generelt tilgængelig den 25. februar 2026, og giver dig en samtalebaseret agent direkte i kommandolinjen uden at åbne en editor overhovedet. Copilot SDK er det tredje lag: biblioteket du bruger til at bygge agenten ind i din egen software.
Forskellen handler i bund og grund om, hvem der ejer brugerfladen. Med IDE-integrationen og CLI’en er det GitHub, der bestemmer, hvordan agenten præsenteres for dig. Med SDK’et bestemmer du det selv, hvilket kræver mere arbejde at sætte op, men giver langt mere fleksibilitet, når du har specifikke krav til sikkerhed, logning eller brugerflade. Ifølge GitHubs egen funktionsoversigt (Copilot feature matrix) varierer den nøjagtige funktionsdækning fra version til version og fra editor til editor, så det er værd at tjekke dokumentationen, før du lover et bestemt sæt funktioner til dit team.
| Egenskab | Copilot i IDE’en | Copilot CLI | Copilot SDK |
|---|---|---|---|
| Hvor den kører | VS Code, JetBrains, Visual Studio | Terminalen | Din egen applikation |
| Generelt tilgængelig siden | Løbende opdateringer | 25. februar 2026 | 2. juni 2026 |
| Målgruppe | Udviklere der koder i editoren | Udviklere der arbejder i terminalen | Teams der bygger egne værktøjer |
| Brugerdefinerede værktøjer | Begrænset via extensions | Begrænset | Fuld kontrol, inkl. override af grep og edit_file |
| MCP-understøttelse | Ja | Ja | Ja, direkte i din egen kode |
| Streaming svar | Ja | Ja | Ja, som en del af API’et |
Et andet aspekt er, hvor godt værktøjerne spiller sammen med resten af branchen. JetBrains har for eksempel med ReSharper 2026.2 taget sit første skridt mod understøttelse af Agent Client Protocol (ACP) i Visual Studio, med deres egen agent Junie tilgængelig som preview-funktion. Det peger mod en fremtid, hvor agenter i stigende grad bliver protokol-kompatible på tværs af IDE’er, i stedet for at være låst til én editor. Når du bygger med Copilot SDK, bygger du altså oven på et økosystem, der også selv er i konstant bevægelse, hvilket er værd at have i baghovedet, når du designer dine egne integrationer.
I praksis betyder det, at du bør designe dine egne værktøjer og tilladelser, så de ikke er hårdkodet til én bestemt editor eller ét bestemt agent-produkt. Hold selve forretningslogikken, for eksempel hvordan et værktøj kører tests eller opretter en pull request, adskilt fra den kode der taler med Copilot SDK specifikt. Så kan du genbruge det meste af arbejdet, hvis dit team på et tidspunkt ønsker at eksponere de samme værktøjer gennem en anden agent eller et andet protokollag.
Sådan er SDK’ets arkitektur bygget op
Før du skriver kode, er det nyttigt at forstå de byggeklodser, SDK’et stiller til rådighed. Arkitekturen er bygget op omkring fire lag: en klient, der håndterer autentificering og kommunikation, en session, der holder styr på samtalehistorik, et sæt værktøjer agenten kan kalde, og en valgfri forbindelse til eksterne MCP-servere. De fire lag kan kombineres på mange måder, men de fleste projekter starter med de samme to trin: opret en klient, og start derefter en session.
Agent-runtime og planlægning
Når du sender en opgave til agenten, planlægger den selv, hvordan opgaven skal løses. Det betyder, at agenten kan bryde en instruktion som “ryd op i dette modul og tilføj tests” ned i flere delopgaver: læs eksisterende kode, identificer manglende testdækning, skriv nye testfiler, og kør testsuiten for at bekræfte at intet er brudt undervejs. Du som udvikler definerer hvilke værktøjer agenten har adgang til, men selve rækkefølgen og beslutningerne tager agenten selv, medmindre du eksplicit begrænser den gennem dine tilladelser. I praksis betyder det, at to identiske opgaver kan blive løst på forskellige måder fra kald til kald, afhængigt af hvilken rækkefølge agenten vurderer er mest effektiv. Det er en vigtig pointe at formidle til resten af teamet: en agent bygget på denne runtime er ikke deterministisk på samme måde som et fast script, og din logning bør derfor være god nok til at forklare, hvilken vej agenten faktisk valgte i en given session.
Værktøjer, tilladelser og MCP
Et værktøj i SDK-sammenhæng er en funktion med et navn, en beskrivelse og et JSON-skema for dens input. Du kan bruge de indbyggede værktøjer som grep og edit_file, overskrive dem med dine egne versioner, eller tilføje helt nye værktøjer specifikt til din organisation, for eksempel opret_jira_sag eller kør_deploy_pipeline. Hvert værktøjskald kan gå gennem en tilladelses-callback, hvor din kode beslutter om kaldet skal godkendes automatisk, afvises, eller sendes til en menneskelig godkender. Endelig kan agenten forbinde til Model Context Protocol-servere, som giver adgang til eksterne datakilder uden at du selv skal bygge integrationslaget fra bunden.
GitHub har samtidig opdateret Copilot i VS Code til at kunne søge efter betydning på tværs af hele arbejdsområdet og køre grep-lignende forespørgsler i hele organisationens repositories. Den funktion blev aktiveret via indstillingen github.copilot.chat.localIndex.enabled i en opdatering til Visual Studio Code fra april 2026, og den samme type søgning kan du bygge videre på, når du designer dine egne værktøjer til SDK’et.
I praksis vil de fleste projekter kun bruge en håndfuld brugerdefinerede værktøjer til at starte med: ét til at køre tests, ét til at hente kontekst fra et internt system, og måske ét til at oprette en pull request. Det er en god tommelfingerregel at holde antallet af værktøjer lavt i starten og først udvide, når du konkret oplever at agenten mangler noget for at løse en opgave, i stedet for at bygge et stort katalog af værktøjer agenten aldrig ender med at bruge.
Trin 1-3: Projektopsætning og autentificering
De første tre trin handler om at få et tomt projekt op at køre med adgang til Copilot-agenten. Start med at oprette en ny mappe, initialisere et Node.js-projekt, og installere SDK’et. Herefter skal du autentificere mod GitHub. SDK’et bruger samme type adgang som Copilot CLI: enten en personal access token med Copilot-rettigheder, eller en interaktiv login-session via GitHubs eget CLI-værktøj gh. Til lokal udvikling er en token i en miljøvariabel oftest det simpleste, mens en CI-pipeline typisk bruger en krypteret secret i stedet.
mkdir copilot-review-agent && cd copilot-review-agent
npm init -y
npm install @github/copilot-sdk
export GITHUB_TOKEN="din-personal-access-token-med-copilot-scope"import { CopilotClient } from "@github/copilot-sdk";
const client = new CopilotClient({
token: process.env.GITHUB_TOKEN,
});
console.log("Copilot-klient oprettet og klar til brug");Trin 4-6: Din første agent-session
Med klienten på plads kan du oprette din første session og sende en opgave af sted. En session holder styr på samtalehistorikken, så agenten husker tidligere beskeder gennem samme forløb. Trin fire er at oprette sessionen, trin fem er at sende en opgave, og trin seks er at læse resultatet, som kommer tilbage som et struktureret svar med den tekst agenten har genereret og en liste over de handlinger, den har udført undervejs.
async function runFirstTask() {
const session = await client.createSession({
workingDirectory: process.cwd(),
});
const result = await session.run({
prompt: "Forklar kort hvad filen package.json indeholder i dette projekt",
});
console.log(result.text);
console.log("Handlinger udført:", result.actions.length);
}
runFirstTask();Trin 7-9: Tilføj brugerdefinerede værktøjer
Den virkelige værdi i SDK’et kommer, når du giver agenten adgang til dine egne værktøjer. Trin syv er at definere et værktøj med navn, beskrivelse og input-skema. Trin otte er at registrere værktøjet på klienten. Trin ni er at teste, at agenten rent faktisk vælger at bruge værktøjet, når en opgave kræver det. Et typisk første værktøj er en funktion, der kører din testsuite og returnerer resultatet, så agenten selv kan afgøre om en ændring er sikker, før den foreslår den til dig.
import { defineTool } from "@github/copilot-sdk";
import { execSync } from "node:child_process";
const runTestsTool = defineTool({
name: "run_tests",
description: "Kører projektets testsuite og returnerer resultatet",
inputSchema: {
type: "object",
properties: {},
},
handler: async () => {
try {
const output = execSync("npm test", { encoding: "utf-8" });
return { success: true, output };
} catch (error) {
return { success: false, output: String(error) };
}
},
});
client.registerTool(runTestsTool);Trin 10-11: Forbind til Model Context Protocol-servere
MCP-forbindelser giver agenten adgang til kontekst uden for dit kodeprojekt. Trin ti er at pege SDK’et mod en kørende MCP-server, for eksempel en der eksponerer din organisations interne dokumentation. Trin elleve er at bekræfte forbindelsen og teste et kald, der henter kontekst fra serveren. Du kan køre en MCP-server lokalt under udvikling og pege på en delt, central server i produktion, uden at skulle ændre resten af din agent-kode.
const session = await client.createSession({
workingDirectory: process.cwd(),
mcpServers: [
{
name: "intern-dokumentation",
url: "http://localhost:4000/mcp",
},
],
});
const result = await session.run({
prompt: "Slå op i intern dokumentation hvordan vi navngiver miljøvariabler",
});
console.log(result.text);Trin 12-13: Streaming svar og multi-turn sessioner
Lange opgaver bør streame deres svar, så brugeren ser fremgang i stedet for at vente på et samlet svar til sidst. Trin tolv er at iterere over svarets dele, mens de kommer ind. Trin tretten er at genbruge samme session til en opfølgende besked, så agenten husker konteksten fra det forrige kald. Det er især nyttigt i en agent, der reviewer kode: du kan først bede om en gennemgang, og bagefter bede agenten rette de fundne problemer, uden at du skal forklare konteksten forfra igen.
const stream = await session.runStream({
prompt: "Gennemgå filerne i src/ og list potentielle fejl",
});
for await (const chunk of stream) {
process.stdout.write(chunk.text);
}
const followUp = await session.run({
prompt: "Ret de tre vigtigste problemer du fandt",
});
console.log(followUp.text);Trin 14: Tilladelser, sikkerhed og produktionsklargøring
Det sidste trin, inden du sætter en agent i produktion, er at lægge et tilladelseslag ind mellem agenten og dine systemer. En permission-callback kører, hver gang agenten vil kalde et værktøj der ændrer noget, for eksempel edit_file eller et deploy-værktøj, og giver din kode mulighed for at godkende, afvise eller eskalere kaldet til en menneskelig godkender, før det rent faktisk udføres.
client.onToolCall(async (call) => {
const risikable = ["edit_file", "run_deploy_pipeline"];
if (risikable.includes(call.toolName)) {
const godkendt = await beOmMenneskeligGodkendelse(call);
return godkendt ? "allow" : "deny";
}
return "allow";
});Log altid hvert værktøjskald, inklusive hvilket input agenten sendte og hvad resultatet blev. Det gør det muligt at rekonstruere, hvad agenten lavede, hvis noget går galt senere, og giver dig data til at stramme op på hvilke værktøjer agenten reelt har brug for over tid. Mange teams opdager først efter et par ugers drift, at agenten aldrig bruger halvdelen af de værktøjer, den fik adgang til fra start.
Før du går fra et lokalt eksperiment til en agent, der kører automatisk på tværs af et team, er det værd at gennemgå en kort tjekliste. Er alle risikable værktøjer dækket af en permission-callback? Er token-forbrug logget pr. session, så en uge med uventet høj aktivitet bliver synlig med det samme? Er der en klar ejer af konfigurationen, som kan svare på, hvilke systemer agenten rent faktisk kan tilgå? De tre spørgsmål fanger langt de fleste problemer, før de bliver til en reel hændelse.
Komplet eksempelprojekt: en kodegennemgangs-agent
Nu samler vi de 14 trin til ét fungerende projekt: en kommandolinje-agent, der gennemgår ændringer i en mappe, kører testsuiten, og foreslår rettelser med menneskelig godkendelse før noget skrives til disk. Filen nedenfor kan gemmes som review-agent.ts og køres direkte med din foretrukne TypeScript-runner.
Koden er bygget op i fire dele, der svarer direkte til trinene ovenfor. Øverst oprettes klienten med token fra miljøvariablen. Derefter registreres værktøjet run_tests, så agenten selv kan verificere sine rettelser. Permission-callbacken beder om et aktivt “ja” i terminalen, hver gang agenten vil redigere en fil, hvilket er en simpel, men effektiv måde at holde et menneske i løkken på i et lille projekt. Til sidst samler main-funktionen det hele: en streamet gennemgang efterfulgt af en opfølgende besked, der beder agenten rette det, den selv fandt.
import { CopilotClient, defineTool } from "@github/copilot-sdk";
import { execSync } from "node:child_process";
import readline from "node:readline/promises";
const client = new CopilotClient({ token: process.env.GITHUB_TOKEN });
const runTestsTool = defineTool({
name: "run_tests",
description: "Kører projektets testsuite og returnerer resultatet",
inputSchema: { type: "object", properties: {} },
handler: async () => {
try {
const output = execSync("npm test", { encoding: "utf-8" });
return { success: true, output };
} catch (error) {
return { success: false, output: String(error) };
}
},
});
client.registerTool(runTestsTool);
client.onToolCall(async (call) => {
if (call.toolName !== "edit_file") return "allow";
const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
const svar = await rl.question("Agenten vil redigere en fil. Godkend? (ja/nej): ");
rl.close();
return svar.trim().toLowerCase() === "ja" ? "allow" : "deny";
});
async function main() {
const session = await client.createSession({ workingDirectory: process.cwd() });
const review = await session.runStream({
prompt: "Gennemgå ændringerne i src/ og list potentielle fejl og sikkerhedsproblemer",
});
for await (const chunk of review) {
process.stdout.write(chunk.text);
}
const rettelse = await session.run({
prompt: "Ret de problemer du fandt, og kør testsuiten bagefter for at bekræfte",
});
console.log("\n" + rettelse.text);
}
main();Når du kører scriptet mod et repository med et par bevidste fejl, kan en typisk session se sådan ud i terminalen.
$ node review-agent.js
Gennemgår filerne i src/...
Fundet 3 problemer:
1. manglende null-check i src/auth.ts linje 42
2. ubrugt import i src/utils.ts linje 3
3. synkront filkald blokerer event loop i src/server.ts linje 88
Agenten vil redigere en fil. Godkend? (ja/nej): ja
Retter problem 1 af 3...
Retter problem 2 af 3...
Retter problem 3 af 3...
Kører testsuite for at bekræfte...
Alle 24 tests bestod. Ændringerne er klar til review i en pull request.5 almindelige faldgruber du skal undgå
De fleste af de alvorlige fejl med Copilot SDK opstår ikke, fordi koden er forkert, men fordi standardopsætningen er for åben i forhold til, hvad agenten reelt har brug for. Her er de fem faldgruber, der går igen oftest, når teams går fra et lille eksperiment til noget, der rører rigtige systemer.
- At give agenten skriveadgang til hele disken i stedet for kun projektmappen. Sæt altid workingDirectory til et konkret, afgrænset sted, og afvis filstier der peger uden for den mappe i din permission-callback, så en fejlagtig prompt ikke kan røre andre projekter på maskinen.
- At springe tilladelses-laget over, fordi “det er bare et testprojekt”. Testmiljøer har ofte adgang til de samme tokens og hemmeligheder som produktion, og en agent der får lov at køre vilkårlige kommandoer uden godkendelse kan hurtigt forårsage skade, selv ved et uskyldigt eksperiment.
- At glemme at sætte en grænse for antal værktøjskald pr. session. Uden et loft kan en agent, der ikke løser en opgave korrekt første gang, ende i en løkke af gentagne forsøg, hvilket både koster tid og øger din regning unødigt.
- At antage agenten altid vælger det rigtige værktøj uden selv at teste edge cases. Test dine værktøjer med tvetydige og modstridende prompts, så du ved hvordan agenten reagerer, før en bruger i produktion rammer samme situation.
- At genbruge samme session på tværs af helt urelaterede opgaver. Konteksten hober sig op og gør svarene mindre præcise, så det er bedre at oprette en ny session, hver gang brugeren starter en ny, adskilt opgave.
Fejlfinding: 8 problemer og løsninger
De fleste problemer med Copilot SDK opstår i de første timer, mens autentificering og netværksadgang bliver sat korrekt op. Når det første kald først virker, flytter fejlene sig typisk til et andet sted: værktøjer der ikke bliver kaldt som forventet, MCP-forbindelser der dropper, eller sessioner der mister kontekst undervejs. Tabellen herunder samler de otte mest almindelige fejl på tværs af begge faser og hvordan du løser dem hurtigt, uden at skulle grave i hele dokumentationen hver gang.
| Problem | Årsag | Løsning |
|---|---|---|
| 401 Unauthorized ved første kald | Token mangler Copilot-scope eller er udløbet | Generer en ny personal access token med Copilot-rettigheder, eller kør en frisk login via gh |
| Agenten hænger og svarer aldrig | Streaming-forbindelsen bliver blokeret af en firewall eller proxy | Tjek at netværkspolitikken tillader udgående HTTPS-trafik, og sæt en proxy-konfiguration i klienten hvis nødvendigt |
| Custom tool bliver aldrig kaldt | Værktøjets skema matcher ikke det agenten forventer | Valider JSON-skemaet separat, og giv værktøjet en tydeligere beskrivelse af hvornår det skal bruges |
| MCP-serveren svarer med timeout | Serveren er ikke startet, eller porten er optaget | Start MCP-serveren separat og test den med en simpel forespørgsel, før du forbinder agenten til den |
| Agenten redigerer de forkerte filer | edit_file er ikke begrænset til projektmappen | Sæt en permission-callback der afviser filstier uden for dit projekt-root |
| Høje omkostninger efter en uge i drift | Ingen grænse på antal agent-kald eller tokens pr. session | Indfør et dagligt loft, og log token-forbrug pr. session for at opdage spidser tidligt |
| SDK’et virker lokalt, men fejler i CI | Miljøvariabler eller token mangler i CI-miljøet | Tilføj token som en krypteret secret i din CI-pipeline, og eksportér den før agent-kaldet køres |
| Multi-turn session glemmer konteksten | Sessionen bliver genstartet mellem kald i stedet for genbrugt | Gem session-id’et, og send det videre i hvert efterfølgende kald i samme forløb |
Avancerede tips til produktion
Når det grundlæggende virker, er der en række justeringer der gør forskellen mellem et sjovt prototype-projekt og noget der kan køre stabilt i produktion over måneder.
- Cache sessioner per bruger i stedet for at oprette en ny for hver eneste forespørgsel. Det reducerer både ventetid og unødvendigt genopbygget kontekst.
- Sæt en hård grænse for antal værktøjskald pr. session, typisk et sted mellem 10 og 30 afhængig af opgavens kompleksitet, for at undgå uendelige løkker.
- Brug streaming i alle brugervendte flows, så oplevelsen føles hurtig selv ved svar der tager flere sekunder at generere færdigt.
- Log token-forbrug pr. session, og sæt en alarm der trigger hvis en enkelt session pludselig bruger markant flere tokens end gennemsnittet.
- Byg et fallback-flow til et billigere, mindre kapabelt værktøj, hvis agenten rammer samme fejl flere gange i træk, i stedet for at lade den blive ved med at prøve.
- Test dine brugerdefinerede værktøjer isoleret, uden agenten involveret, før du kobler dem sammen. Det gør det meget lettere at finde ud af, om en fejl stammer fra værktøjet selv eller fra agentens brug af det.
- Gennemgå permission-loggen ugentligt i de første måneder efter lancering, så du kan stramme op på rettigheder agenten reelt aldrig bruger.
Ingen af disse tips kræver, at du implementerer dem alle på én gang. Start med grænser på værktøjskald og logning af token-forbrug, fordi de to ting beskytter dig mod de dyreste fejl. Tilføj derefter streaming og caching, når du har en god fornemmelse for, hvordan dine brugere faktisk interagerer med agenten. Fallback-flows og isoleret test af værktøjer kan med fordel vente, til du har kørt i produktion i et par uger og har konkrete fejl at designe ud fra, fremfor at gætte dig frem på forhånd.
Hvilket sprog skal du vælge til dit projekt?
SDK’et understøtter flere sprog, og valget afhænger mest af, hvad resten af dit team allerede arbejder i. Node.js og TypeScript installeres med npm install @github/copilot-sdk og passer godt til webapps, CLI-værktøjer og Electron-baserede desktop-apps. Python installeres med pip install github-copilot-sdk og egner sig til data-pipelines, automatisering og Jupyter-integrationer, hvor resten af koden allerede er i Python. Go tilføjes med go get github.com/github/copilot-sdk og er et solidt valg til hurtige CLI-binaries og Kubernetes-operatorer, hvor lav opstartstid betyder noget.
.NET tilføjes med dotnet add package GitHub.Copilot.SDK og passer til enterprise-applikationer bygget på .NET, samt til teams der allerede bygger udvidelser til Visual Studio. Rust tilføjes med cargo add github-copilot-sdk og giver mening i performance-kritiske værktøjer eller systemnære agenter, hvor hukommelsesforbrug og opstartstid skal holdes minimalt. Java integreres via Maven eller Gradle og er det naturlige valg, hvis din agent skal leve inde i en eksisterende JVM-baseret backend, for eksempel en Spring-applikation, i stedet for som et separat projekt ved siden af.
Hvis du er i tvivl, så lad eksisterende infrastruktur afgøre valget frem for personlige præferencer. En agent, der skal trigges fra en GitHub Actions-workflow, passer typisk bedst som et lille Node.js- eller Python-script, fordi begge sprog har hurtig opstartstid og enkel afhængighedshåndtering i CI-miljøer. En agent, der skal køre som en langtidslevende service ved siden af en eksisterende backend, bør derimod følge det sprog den backend allerede er skrevet i, så teamet ikke pludselig skal vedligeholde endnu en runtime og endnu et sæt deployment-pipelines ved siden af det, de i forvejen har.
Ofte stillede spørgsmål
Hvad koster det at bruge GitHub Copilot SDK?
SDK’et kræver et aktivt GitHub Copilot-abonnement, da kaldene går gennem den samme agent-runtime som resten af Copilot-produkterne. Der er ikke oplyst en separat prisstruktur ud over dit eksisterende abonnement, så budgettér efter hvor mange agent-kald dit projekt forventes at lave om måneden.
Kan jeg bruge SDK’et med et Copilot Individual-abonnement, eller kræver det Business?
GitHub har ikke offentliggjort en detaljeret oversigt over, nøjagtigt hvilke abonnementstrin der giver adgang til hvilke SDK-funktioner. Tjek altid den aktuelle Copilot feature matrix i GitHubs dokumentation, før du lægger en plan for et større projekt, og involvér gerne den, der administrerer jeres GitHub-organisation, tidligt, så I ikke opdager en begrænsning midtvejs i et større udviklingsforløb.
Virker SDK’et sammen med Model Context Protocol (MCP)?
Ja. Du kan pege en session mod en eller flere MCP-servere ved oprettelse, og agenten kan derefter hente kontekst fra dem i samme flow som den bruger dine øvrige værktøjer.
Hvad er egentlig forskellen på Copilot SDK og Copilot CLI?
Copilot CLI er en færdig, terminal-native brugerflade som GitHub selv bygger og vedligeholder, mens Copilot SDK er byggeklodserne du selv bruger til at skabe din egen brugerflade, hvad enten det er en CLI, en webapp eller en intern bot. Mange teams bruger faktisk begge dele: Copilot CLI til hurtige, manuelle opgaver i terminalen, og et SDK-baseret projekt til de automatiserede flows der skal køre uden en person til stede.
Kan jeg køre min agent med en lokal model i stedet for GitHubs egen?
SDK’et er bygget til at tale med Copilots agent-runtime, og den dokumenterede vej er gennem GitHubs egen infrastruktur. Hvis du har brug for en helt lokal model uden netværksadgang, for eksempel af compliance-årsager i en meget lukket organisation, bør du undersøge, om det passer bedre til dit projekt at bruge et separat, lokalt agent-framework i stedet for at forsøge at tvinge SDK’et til at pege på en anden model-udbyder.
Hvor sikkert er det at give en agent adgang til at redigere filer?
Det afhænger helt af, hvordan du konfigurerer dine tilladelser. Uden en permission-callback kan edit_file i princippet ændre enhver fil agenten kan se. Med en veldesignet callback, der begrænser omfanget og kræver godkendelse ved risikable kald, kan du holde risikoen på et niveau der svarer til en almindelig code review.
Understøtter SDK’et andre sprog end TypeScript?
Ja. Ud over Node.js og TypeScript findes der understøttelse til Python, Go, .NET, Rust og Java, som alle er beskrevet tidligere i guiden med deres respektive installationskommandoer. Den underliggende API’en er konceptuelt den samme på tværs af sprogene, så koncepterne fra denne guides TypeScript-eksempler, klient, session, værktøj og permission-callback, overføres direkte, selv om den konkrete syntaks naturligvis varierer fra sprog til sprog.
Hvordan undgår jeg uventet store regninger fra agent-kald?
Sæt en hård grænse for antal værktøjskald pr. session, log token-forbrug løbende, og byg en alarm der reagerer, hvis en enkelt session bruger markant mere end gennemsnittet. De fleste store regninger stammer fra løkker, hvor agenten gentager det samme mislykkede forsøg uden en grænse der stopper den.
Skal jeg omskrive hele projektet, når GitHub udgiver en ny version af SDK’et?
Nej, ikke nødvendigvis. Da SDK’et nu er generelt tilgængeligt, bør nye versioner som udgangspunkt være bagudkompatible inden for samme hovedversion. Følg alligevel GitHubs ændringslog, før du opdaterer et produktionsprojekt, og test opdateringen i et isoleret miljø, hvor du kan sammenligne agentens adfærd før og efter, da ændringer i den underliggende model også kan ændre, hvordan agenten vælger mellem dine værktøjer.