Copilot i JetBrains kräver IDE 2025.2 eller senare

Vad ändrades i beskedet den 10 oktober?

Copilot har avslutat stödet för JetBrains IDE 2025.1. Pluginen kräver nu IDE 2025.2 eller senare, enligt GitHubs besked den 10 oktober 2026. För ett svenskt utvecklarteam är versionsinventeringen därför första uppgiften.

Beskedet visar en supportgräns. Det visar inte att varje befintlig installation omedelbart slutar fungera. En fungerande äldre installation är samtidigt inget underlag för att godkänna nästa uppdatering. Håll isär vad som startar på en viss dator och vilken miljö leverantören uppger att pluginen behöver.

Bestäm vem som äger uppgraderingsbeslutet: utvecklaren för en egen arbetsmiljö eller den som förvaltar teamets gemensamma installation. Lägg versionskontrollen i samma underlag som övriga verktygsbyten. Om ett projekt är beroende av en särskild IDE-integration behöver dess resultat ingå i beslutet, även om Copilot fungerar i ett tomt projekt.

Inventera IDE och plugin var för sig

Skriv ned IDE-produkt, fullständig IDE-version och installerad Copilot-pluginversion för varje miljö som ska omfattas. Komplettera med projekt, ansvarig och om installationen hanteras centralt. Utgå från vad som faktiskt finns installerat, inte från senaste numret i teamets installationsguide.

Ta också med vilka funktioner arbetet kräver. Ett team kan behöva chatt och agentarbete men sakna beroende av MCP. Ett annat behöver en konfigurerad MCP-server för att hämta intern dokumentation. Skriv dessa krav uttryckligen; annars kan samma prov bli godkänt av en person och underkänt av en annan.

GitHubs besked anger inget pluginnummer. Kontrollera kompatibiliteten för den pluginversion ni tänker installera på pluginens versionssida i JetBrains Marketplace innan ni väljer målversion. Den offentliga IDE-gränsen ersätter inte den kontrollen.

Prova uppgraderingen utan att skriva över arbetsmiljön

Välj en representativ miljö och ett litet projekt för pilotprovet. Spara eller exportera de lokala inställningar ni behöver kunna återställa innan installationen ändras. Dokumentera hur ni återgår till den tidigare miljön. Om installationsverktyget erbjuder separat installation eller profil, kontrollera vad det faktiskt isolerar innan ni använder den för provet.

Undvik att låta en oprövad inställningssynk ersätta det sparade underlaget. Anteckna vilka inställningar som följde med och vilka som behövde läggas in igen. Om pilotmiljön saknar en obligatorisk integration ska den observationen stå i protokollet; fyll inte i godkänt utifrån att själva editorn öppnades.

Använd samma projekt och samma uppgift före och efter bytet. Be exempelvis chatten förklara en liten funktion och ange vilken fil svaret bygger på. Låt sedan agenten föreslå en avgränsad ändring på en testgren. Granska diffen och kör projektets relevanta test. Håll uppgiften liten nog att granskaren kan avgöra om ändringen svarar på beställningen.

Standardmodell och eget modellval är olika kontroller

Enterprise-administratörer kan välja en tillgänglig agentmodell som standard för nya konversationer via hanterade inställningar. Ett uttryckligt val i modellväljaren bevaras, enligt samma GitHub-besked från 10 oktober.

För provet behöver ni därför skriva ned både organisationens avsedda standard och användarens uttryckliga val. Starta en ny konversation utan ett eget modellval och anteckna vad gränssnittet visar. Gör sedan ett uttryckligt val och prova igen. Ett återanvänt samtal med ett tidigare val besvarar inte frågan om startläget för ett nytt samtal.

Har teamet inte en sådan Enterprise-inställning ska raden markeras som inte tillämplig. Låt den inte bli en förutsättning för att bedöma IDE-uppgraderingen. Håll även modellkvalitet separat: att rätt modell visas betyder inte att den föreslagna kodändringen klarar projektets test.

Kontrollera den nya inställningen för MCP-start

En ny MCP-inställning kan stänga av automatisk serverstart för Copilot och Claude, enligt GitHubs besked den 10 oktober. Beskedet beskriver startkontroll, inte en generell förändring av verktygens åtkomstregler.

Lista de konfigurerade servrar pilotmiljön ska använda och markera vilka som är obligatoriska. Prova startläget med automatisk start avstängd och dokumentera den observerade serverstatusen. Starta sedan den avsedda servern via miljöns tillgängliga startfunktion och gör ett litet, tillåtet anrop. Använd testdata eller ett läsanrop där det räcker för att verifiera integrationen.

Kontrollera hela kedjan: servern kan startas, verktyget visas och anropet ger det väntade resultatet. Ett synligt servernamn räcker inte som godkännande. Skilj ett anslutningsfel från saknad behörighet och från en server som ännu inte startats. Skriv felkategori och nästa åtgärd utan att lägga tokenvärden eller interna svar i ett öppet protokoll.

Avsluta med ett beslut som går att granska

Använd följande checklista som AI-kreatörs förslag till godkännande av pilotmiljön. Den är ett eget provupplägg, inte ett testresultat från GitHub:

• IDE och plugin: installerade versioner, vald målversion och kontrollerad kompatibilitet är noterade.
• Inställningar: sparat underlag och återgångsväg finns, och nödvändiga lokala inställningar har kontrollerats.
• Chatt: rätt projektkontext används och svaret kan knytas till den avsedda filen.
• Agent: beställd ändring har en granskad diff och relevant testresultat.
• Modellval: standardläget och ett uttryckligt val har prövats om hanterade inställningar används.
• MCP: varje obligatorisk server har ett observerat startläge och ett lyckat avgränsat verktygsanrop.

Stoppa utrullningen om en obligatorisk integration misslyckas eller om provet inte kan genomföras. Markera oprövat som oprövat och ge felet en ansvarig. Ett pilotbeslut ska också ange vilka IDE-produkter och projekt det omfattar; det går inte att godkänna hela teamets miljö med ett resultat från en annan produktvariant.

Efter ett godkänt prov kan ni planera resten av uppgraderingen utifrån inventeringen. Använd guiden till AI-verktyg för programmering för verktygsvalet och arbetsflödet för AI-assisterad utveckling för kopplingen mellan uppgift, granskning och test. Det är de återkommande kontrollerna som gör nästa versionsbyte enklare att bedöma.