LM Studio förklarar vad Auto Review släpper igenom – och vad den uttryckligen inte fångar

LM Studio publicerade den 27 augusti 2026 en teknisk genomgång av Auto Review, ett godkännandeläge för shell-kommandon som väljs i godkännandemenyn i företagets agent Bionic. Texten är skriven av Ryan Huang och förklarar i detalj hur ett kommando kan köras utan att du bekräftar det. Det intressanta ligger dock inte i att funktionen finns. Det ligger i att inlägget under en egen rubrik räknar upp vad mekanismen förutsätter, och att en av punkterna handlar om något som står på din maskin och inte i deras kod. Kör du en lokal agent med rätt att köra kommandon är den listan viktigare än pipelinen.

Två grindar i följd, och bara den första är deterministisk

Varje kommando agenten vill köra passerar det inlägget kallar auto review-pipelinen. Första steget är Shell Judge, som beskrivs som en särskilt byggd, deterministisk analysator för shell-kommandon med en omfattande lista över kända säkra kombinationer av kommando och argument. Inlägget säger uttryckligen att det steget ännu inte involverar någon språkmodell. Bedöms kommandot som definitivt säkert körs det direkt.

Klarar Shell Judge inte det går kommandot vidare till steg två: en separat granskaragent, Shell Reviewer, som läser huvudsessionens transkript och avgör om kommandot får köras. Poängen med tvåstegsupplägget är kostnad. Att låta en språkmodell granska varje kommando blir dyrt fort, och Shell Judge finns för att släppa igenom så mycket som möjligt mekaniskt.

Hur mycket det är i praktiken redovisar inlägget med en siffra som är värd att läsa exakt som den står: i sin nuvarande version kan Shell Judge automatiskt godkänna upp till 82 procent av alla kommandon som författarens egen agent kör. Författaren kallar själv siffran anekdotisk men ändå en signal. Det är alltså en observation från en utvecklares egna sessioner, inte en uppmätt andel för en typisk installation, och inte något du kan räkna med på din maskin utan att titta efter. Motsvarande gäller den andra siffran i texten: testsviten för Shell Judge omfattade 11 651 tester vid publiceringen, och antalet uppges fortsätta växa. Ett stort antal tester säger något om ambitionen, ingenting om täckningen mot ditt fall.

Shell Judge tillåter bara det den fullt ut förstår

Mekaniskt består steget av tre delar: kommandot parsas till ett AST, ett förmågeobjekt extraheras, och det matchas mot regler. Förmågeobjektet svarar enligt inlägget på frågan vad kommandot i värsta fall kan göra. Principen är en allowlist i strikt mening: ser analysen en AST-struktur den inte känner igen rapporteras den som okänd och kommandot avvisas. Bara kommandon som förstås fullt ut släpps igenom.

Konsekvenserna är konkreta nog att kännas igen. Sätts eller exporteras en miljövariabel för ett kommando avvisas det direkt, med motiveringen att miljövariabler kan ändra ett kommandos beteende i grunden och möjliggöra godtycklig kommandokörning — inläggets eget exempel är en git-variabel som pekar ut en extern diff-motor. Även en vanlig tilldelning avvisas om namnet redan är en miljövariabel, till exempel PATH, eftersom tilldelningen då ändrar miljön även utan export. Bedömningen av ett kommando beror alltså på vilka miljövariabler som råkar finnas när det körs.

Analysen håller också reda på vilka värden en variabel kan ha, i en konstruktion inlägget kallar ändliga alternativ. Tilldelas variabeln om och om igen i en loop ges spårningen upp, och antalet alternativ som följs är begränsat till 1 000 för att undvika exponentiell explosion. Går värdet inte att utvärdera avvisas kommandot, eftersom värdet i värsta fall kan vara ett sökvägsmönster som expanderar och röjer filer.

Att filsystemet modelleras framgår tydligast av inläggets eget par, där omslutning och variabelnamn är identiska och bara värdet skiljer:

target="notes.txt";    echo "done" > $target   # tillåts
target="/etc/passwd";  echo "done" > $target   # tillåts inte

Samma resonemang styr reglerna. Regeln för cat kräver att positionsargumentet är en läsbar fil eller standard in, vilket är skälet till att cat mot systemets lösenordsfil avvisas medan cat mot en textfil i arbetskatalogen tillåts. Vissa kommandon är säkra bara med en viss flagga: node i allmänhet är det inte, medan node med versionsflaggan är det, och egna regler tillåter dessutom hjälp- och syntaxkontrollflaggorna. Argumentparsningen modelleras dessutom per program, eftersom program skiljer sig åt — inlägget kontrasterar ls -la, som motsvarar två separata flaggor, mot TypeScript-kompilatorn där den sammanslagna formen avvisas.

De tre antagandena står i klartext, och det första är ditt

Under rubriken om kända avvägningar och antaganden redovisar inlägget tre eftergifter. Den första är den som betyder något för dig i dag: miljön antas vara normal och icke-fientlig. Att git verkligen är git och inte något annat som bär namnet. Motivet är att det är orealistiskt att inspektera varje binär. Samma antagande gäller konfiguration: är git inställt att köra skadlig kod som diff-motor, eller ett formateringsverktyg inställt att ladda ett illvilligt tillägg, så kan Shell Judge enligt inlägget inte rädda dig. Det är källans egen formulering, inte en skärpning härifrån.

Det är därför det första provet du ska göra inte handlar om agenten alls. Kör git config --list --show-origin och läs igenom vad som faktiskt är satt och varifrån. Leta efter externa diff- och textkonverteringsinställningar, efter rensnings- och utsmetningsfilter, efter en omdirigerad hook-katalog och efter alias som döljer helt andra kommandon. Gör motsvarande genomgång av projektets beroendekonfiguration: formaterings- och lintverktyg som laddar tillägg, och paketmanifest med skript som körs vid installation. Varje sådan post är ett program som startar utan att stå i kommandoraden, och det är exakt den kategori Shell Judge säger sig inte täcka. Det är samma disciplin som gäller när en sårbarhet i llama-server kräver att du kontrollerar ditt eget bygge i stället för att lita på en rubrik: kontrollen görs på din maskin, med dina inställningar.

De två övriga antagandena är smalare men hör till bilden. Systemets temporära kataloger antas alltid vara åtkomliga och åtkomsten till dem modelleras inte. Och att verktyg läser konfiguration utanför den läsbara katalogen betraktas som normalt, exempelvis att Git läser sin globala inställningsfil. Båda är rimliga förenklingar. Båda är också luckor i modellen, redovisade som sådana.

Vilket skal kör din agent egentligen?

Shell Judge anges stödja fyra skal: sh, bash, zsh och PowerShell. För sh, bash och zsh används ett tredjepartsbibliotek för parsningen, och för PowerShell används PowerShell självt för att bygga trädet. Separat från den listan beskriver inlägget vilket skal Bionic väljer: på macOS föredras zsh, och på Windows föredras Git Bash om det är installerat, annars faller agenten tillbaka på PowerShell och därefter på cmd.

Läs de två uppräkningarna bredvid varandra. Cmd står med i återfallskedjan men inte bland de fyra skal Shell Judge anges stödja, och inlägget säger ingenting om vad som händer med den mekaniska godkännandegraden i det läget. Här slutar källan, och därför slutar den här texten också: det är en öppen fråga, inte ett påstående om att något är sämre.

Provet är enkelt och tar en minut. Kör du Windows, kontrollera om Git Bash finns installerat på maskinen, eftersom det är det som avgör vilken gren av kedjan som gäller dig. Be sedan agenten skriva ut vilket skal den själv körs i och notera svaret i din driftanteckning, på samma sätt som driftguiden kräver att modell, runtime och konfiguration antecknas per version. Utan det svaret vet du inte vilken av de två uppräkningarna som beskriver din uppsättning.

Granskaren klassificerar, den dömer inte

Steg två är konstruerat kring en idé som är lätt att missa: huvudagenten ska inte veta att dess kommando granskas, och granskaren ska inte veta att den avgör om ett kommando får köras. Motivet är erfarenhetsmässigt. En granskare som förstår sin roll tenderar enligt inlägget att sympatisera med huvudagenten och stämpla igenom det som behövs för att lösa uppgiften, och en huvudagent som förstår rollen kan försöka övertala granskaren. Lösningen är att granskaren får bedömningsmallen men inte godkännandegränsen.

Mallen har tre ortogonala axlar, med källans egna värden. Risk kan vara låg, hög eller för destruktiv. Auktorisation svarar på om användaren har sagt sig vilja köra kommandot och kan vara uttryckligt nej, neutral eller uttryckligt ja. Korrekthet fångar uppenbara fel — inlägget noterar att frontier-modeller ofta gör citeringsfel, särskilt i PowerShell, och att en egen granskarsession är påfallande bra på att upptäcka dem. Korrekthetsomdömet skickas vidare till huvudmodellen, eftersom korrekthet är ortogonal mot säkerhet.

Grundlogiken är att lågriskkommandon körs om du inte uttryckligen sagt nej, medan högriskkommandon kräver belägg för att du faktiskt ville köra dem. Två regler är värda att veta utantill. Ett kommando som klassas som för destruktivt körs inte, inte ens om du uttryckligen tillåtit det; inläggets exempel är att radera hela hemkatalogen. Och utom i just det fallet får modellen inte veta att ett kommando avvisats — frågan går i stället till dig, för att modellen inte ska kunna arbeta runt granskaren.

Den sista regeln ger dig ett prov du kan göra i vardagen, utan verktyg. Får du en bekräftelsefråga på ett kommando som ser trivialt ut, mitt i en session som annars flyter, är det inte nödvändigtvis ett gränssnittsfel. Det är den återkoppling konstruktionen ger dig när granskaren har sagt nej, eftersom modellen själv inte informeras om avvisningen. Behandla den frågan som information om kommandot, inte som ett hinder att klicka bort.

Dina egna meddelanden är bevisningen

Auktorisationsaxeln frågar om användaren har sagt att kommandot ska köras, och underlaget för det svaret är transkriptet. Varje gång granskaren utlöses skickas samtalet från förra granskningen fram till nu, med kontextbudget och trunkering, och med separata budgetar för dina meddelanden och för allt annat — just för att dina meddelanden bär preferenserna. Assistentens meddelanden ingår också, eftersom det är vanligt att agenten föreslår något och du svarar bekräftande. Utan förslaget kan granskaren inte veta vad ditt ja gällde.

Här ligger den fallgrop som är lättast att gå i. Ett brett medgivande tidigt i sessionen — den där repliken om att köra på med vad som behövs — är inte ett engångsbeslut. Det är text i transkriptet som en granskare senare kan läsa som uttryckligt ja för ett kommando du inte hade i tankarna när du skrev det. Inlägget drar inte den slutsatsen; den följer av hur axeln och urvalet beskrivs, och den är värd att ta på allvar.

Provet: bläddra tillbaka i din senaste agentsession och läs dina egna tio senaste meddelanden som om du var en granskare utan tillgång till verktygsresultat. Vilka av dem skulle du klassa som uttryckligt ja, och för hur brett formulerade åtgärder? Är svaret obehagligt brett har du en vana att ändra, och den ändringen kostar ingenting.

Promptinjektion är inte löst, och sandlådan löser det inte heller

Verktygsresultat utesluts avsiktligt ur granskarens underlag. Skälet är promptinjektion: transkriptet matas in som ett användarmeddelande, och modeller är tränade att värja sig mot injektion i verktygsresultat men inte i det läget. Inlägget stannar dock inte där, utan medger i klartext att fullständigt skydd mot promptinjektion är omöjligt — är huvudagenten redan komprometterad kan den injicera en prompt genom att lägga den i sin egen utdata, som ingår i granskarens kontext.

Lika rakt är avsnittet om sandlådor. Uppfattningen att en sandlåda löser allt beskrivs som en missuppfattning, och problemet Auto Review adresserar som ortogonalt mot sandlådan. Två skäl anges: många kommandon behöver läsa filer utanför den skrivbara katalogen, som Gits globala konfiguration, och du vill ofta att agenten gör något utanför sandlådan över huvud taget — en konfigurationsändring, en installation, en sökning i systemet.

Slutsatsen att dra av de två avsnitten är inte att mekanismen är svag. Den är att den är avgränsad, och att avgränsningen är utskriven av leverantören själv. Auto Review flyttar ditt arbete från att godkänna varje kommando till att godkänna de kommandon en granskare inte kunde placera. Den gör inte agenten säker, och inlägget påstår inte heller det. Var gränsen mellan din maskin och omvärlden går är fortfarande en fråga du får besvara själv, med samma inventering som integritetsguiden beskriver — särskilt eftersom uppgiften om att Bionic är Zero Data Retention som standard, och att företaget varken samlar in eller analyserar användares data, är LM Studios egen utfästelse och inget du kan avläsa i din egen drift.

Fem kontroller du kan göra i dag

• Verktygskonfigurationen. Lista dina git-inställningar med ursprung och leta efter externa diff-motorer, filter, omdirigerade hooks och alias. Lägg till formateringsverktygens tillägg och installationsskript i projektet. Det är den kategori antagandet om en icke-fientlig miljö uttryckligen lämnar åt dig.
• Skalet. Ta reda på vilket skal agenten startar, och på Windows om Git Bash finns installerat. De fyra stödda skalen och återfallskedjan är två olika listor i samma inlägg.
• Dina medgivanden. Läs dina tio senaste meddelanden i en session som en granskare skulle läsa dem. Breda medgivanden lever kvar i transkriptet längre än du tror.
• Bekräftelsefrågorna. Notera vilka kommandon som faktiskt landar hos dig under en arbetsdag. Utom vid för destruktiva kommandon går avvisningen inte till modellen utan till dig, så din egen notering är det underlag som finns.
• Miljövariablerna. Kommandon som sätter eller exporterar en miljövariabel avvisas mekaniskt. Har du vanor som bygger på att prefixa kommandon med variabler kommer de att ta vägen om granskaren i stället för att godkännas direkt.

Sammanfattningsvis är det här ett ovanligt öppet inlägg om en säkerhetsmekanism, och öppenheten är hela nyhetsvärdet. Auto Review beskriver sig som ett sätt att slippa läsa varje kommando, byggt på en deterministisk grind med redovisade luckor och en granskaragent med en redovisad blind fläck. Frågan du ska ställa är inte om mekanismen är bra, utan om de tre antagandena stämmer på din maskin. Två av dem kan du kontrollera i dag. Det tredje — att programvaran du redan har installerat är den den utger sig för att vara — är en fråga du behöver ställa oavsett vilken agent du kör, och den är äldre än både Auto Review och valet mellan Ollama och LM Studio.

Källor

• LM Studio, "How Auto Review works in Bionic", 27 augusti 2026 av Ryan Huang — pipelinen, Shell Judges tre steg, de fyra stödda skalen och skalordningen, allowlist-principen, avvisningen av miljövariabler, gränsen på 1 000 alternativ, filparet med samma omslutning, regelexemplen, de 11 651 testerna, 82-procentssiffran med sin anekdotiska märkning, de tre antagandena, granskarens tre axlar och värden, regeln om för destruktiva kommandon, urvalet till transkriptet, medgivandet om promptinjektion, sandlådeavsnittet och uppgiften om Zero Data Retention
• LM Studios bloggindex — daterar "Introducing LM Studio Bionic: the AI agent for open models" till 16 juli 2026 och belägger vad Bionic är, vilket Auto Review-inlägget förutsätter utan att förklara

Källorna kontrollerades 28 augusti 2026, dagen efter publiceringen. Inlägget är läst i sin helhet hos LM Studio, inklusive kodblocken och avsnitten om antaganden, promptinjektion och sandlåda. Ingen egen installation av Bionic och inget eget prov ligger bakom texten; inga tider, andelar eller mätvärden för Auto Review är egna. Inlägget anger inget versionsnummer, ingen prisuppgift, ingen plattformslista och inget om huruvida läget är påslaget som standard, så inget av det står här heller. Kontrollerat igen 19 september 2026: inlägget är oförändrat och bär ingen uppdateringsnotis; siffrorna 82 procent, 11 651 tester och taket på 1 000 alternativ står kvar som de citeras här. Nästa kontroll sker när LM Studio publicerar en uppföljning om Auto Review eller senast 28 november 2026.