Fra personlig Claude til Teams-konto — uden at miste opsætningen

Det meste af min reelle arbejdshukommelse det sidste år har boet inde i en personlig Claude-konto. Samtaler, Projects, halvt skrevne prompts jeg aldrig blev færdig med, custom Styles jeg havde finjusteret til bestemte slags skriverier, og en ~/.claude/-mappe der stille og roligt var vokset til noget jeg nødigt ville miste. Da det blev tid til at sætte et Teams-workspace op til klientarbejde, var min første antagelse naiv: Anthropic har da en migrationssti. Det har de faktisk ikke. Den personlige konto bliver personlig, Teams-kontoen starter på bar bund, og i flere måneder betaler man for begge dele.

Det er fint nok, når man holder op med at forvente noget andet. Det interessante spørgsmål er ikke “hvordan migrerer jeg” — der er ingenting at migrere. Det er, hvordan man kører de to konti rent samtidig, slæber de brugbare dele af den gamle opsætning med over i hånden, og har en tredje agent i baghånden til det arbejde ingen af de to bør lave. Det er, hvad dette indlæg handler om.

Hvad der faktisk følger med (næsten ingenting)

Anthropic er klare omkring det i deres supportdokumenter, selv om man skal klikke lidt for at finde det. En Teams-organisation kan ikke overtage en personlig Claude-konto. Der er ingen merge, ingen import, ingen “tag mine Projects med”-guide. Man kan eksportere sin personlige kontos data som JSON fra indstillingerne, men der er ingen steder at importere det igen i Teams-workspacet. Samtaler, Projects, Styles, memory — alt bliver, hvor det blev skabt.

Enterprise er en undtagelse: en Enterprise-organisation med et verificeret domæne kan overtage personlige konti under det domæne. Men på Teams starter man fra nul. For et enmandsfirma eller et lille team er det vejen, uanset om man kan lide det eller ej.

Sådan trækker man alligevel det vigtige med over

Det interessante trick er, at man faktisk ikke har brug for en import-knap. Claude’s UI giver to værktøjer, der tilsammen klarer det meste af arbejdet — de er bare ikke skiltet som migrationsfunktioner.

Memories kan eksporteres manuelt. Den personlige kontos memory-funktion har et eksportflow, der genererer en prompt — en lang, struktureret prompt designet til at blive fodret til en hvilken som helst LLM (Claude, ChatGPT, en lokal model, hvad som helst), så den kan opsummere indholdet af memory-filen til noget, man kan klistre direkte ind i Teams-kontoens memory. Det er et fiffigt taskenspillertrick: der er ingen API-forbindelse mellem de to konti, men prompt-som-protokol gør, at man kan flytte substansen uden bytes.

Gamle chats kan opsummere sig selv på forespørgsel. For enhver samtale, der er værd at beholde — en projektopstart, en lang debugging-session, frem-og-tilbagen hvor man regnede et knudret mønster ud — klistr en prompt som denne ind:

Opsummer hele denne samtale med henblik på at flytte den til en anden Claude-instans. Tag den vigtigste kontekst med, beslutninger, kodemønstre og åbne spørgsmål. Sigt efter noget en anden Claude kunne tage op koldt og fortsætte fra.

Resultatet er typisk to-femhundrede ord af destilleret kontekst. Klistr det ind i Teams-workspacet som første besked i en ny samtale (eller vedhæft det til et Project), og man har flyttet den del, der faktisk betød noget. Det meste chathistorik er dødvægt, man alligevel ikke læser igen — vær hård i sit udvalg.

Projects flytter ikke med, men de kan opsummere sig selv. Det værdifulde i et Project er sjældent samtalehistorikken. Det er den akkumulerede kontekst — systemprompten, den tilknyttede Style, vedhæftede filer, mønstrene i hvordan man har brugt det. I stedet for at kopiere noget af det i hånden, åbn det aktuelle Project på den personlige side og spørg det direkte:

Opsummer hele dette Project — instruktioner, vedhæftet viden, tilbagevendende mønstre i hvordan jeg har brugt det — til én systemprompt, jeg kan klistre ind i et nyt Project på en anden Claude-konto. Sigt efter noget selvberoende, der reproducerer arbejdskonteksten.

Output er typisk et par hundrede ord. Opret det nye Project i Teams-workspacet, klistr opsummeringen ind som systemprompt, vedhæft de filer opsummeringen henviser til, og man har flyttet substansen. De fleste Projects overlever den slags kompression overraskende godt — den lange hale af samtalehistorik trak alligevel ikke meget af lasset.

Mønstret går igen i alle tre tilfælde: det meste, man vil “migrere”, er småt, struktureret og kan flyttes som tekst via udklipsholderen. Selve samtalerne er som regel ikke umagen værd.

Side om side: tre Claude’r, ikke to

Browseren er den nemme halvdel. En separat browserprofil, en Firefox-container eller bare en helt anden browser — claude.ai’s session ligger i cookies og opfører sig som enhver anden web-app. Jeg bruger en dedikeret Chrome-profil pr. konto, navngivet efter workspacet. Skift er ét klik på profil-ikonet.

Claude Code er, hvor det bliver interessant, fordi claude /login er en model med én konto ad gangen. Man er logget ind, eller man er ikke. Skift betyder at logge ud og logge ind igen — fint til lejlighedsvis brug, men ubrugeligt hvis man prøver at arbejde i to terminaler samtidig, en mod personlig Max og en mod en klients Teams-workspace.

Min faktiske opsætning kører tre navngivne PowerShell-funktioner, ikke to:

• claudeme — den personlige konto
• claudework — umages Teams-workspace
• claudelocal — Claude Code peget mod en lokal Ollama-endpoint, der kører en stærk kodemodel (lige nu qwen3.6:35b, skiftet ud efterhånden som bedre modeller dukker op). Den fungerer som en juniorudvikler, der kan trælle sig gennem rutinearbejde uden at brænde cloud-kvote af.

Tricket bag alle tre er én miljøvariabel pr. shell. CLAUDE_CONFIG_DIR skifter mappen med credentials, settings, hooks og skills; ANTHROPIC_BASE_URL peger den samme binær mod en lokal server, der taler Anthropic Messages API. Kombiner de to, og man har tre helt uafhængige identiteter, der deler én Claude Code-installation.

Én binær fil, tre identiteter — to cloud-konti og én lokal model — adskilt af miljøvariabler.

Et forbehold, der er værd at være ærlig om: CLAUDE_CONFIG_DIR står ikke på Anthropic’s officielle liste over miljøvariabler. Variablen er udbredt og stabil i praksis, og indholdet af ~/.claude/ er dokumenteret særskilt, men Anthropic har ikke formelt velsignet override’et endnu. Behandl det som den de facto-standard, det er, men bliv ikke overrasket, hvis dokumentationen kommer efter.

Et andet forbehold gælder den lokale bane. ANTHROPIC_BASE_URL er officielt dokumenteret som en enterprise LLM-gateway-indstilling — til at route Claude Code gennem Bedrock, Vertex eller en intern proxy. At pege den mod en lokal Ollama er samme mekanisme, men lokale LLM’er er ikke et navngivet use case. Det virker, fordi Ollama taler Anthropic Messages API; behandl det som funktionelt, men uofficielt, på samme måde som CLAUDE_CONFIG_DIR-tricket. Anthropic’s Usage Policy gælder stadig for, hvad man beder Claude Code om at gøre, uanset hvilken backend der serverer svaret.

Sådan har jeg sat det op

Jeg har to config-mapper liggende side om side: standardmappen ~/.claude/ til personlig brug og ~/.claude-work/ (startet tom, fyldt op efterhånden) til Teams-workspacet. På Windows bor de tre funktioner i min PowerShell-profil:

function claudeme   { $env:CLAUDE_CONFIG_DIR = "$HOME\.claude";       claude @args }
function claudework { $env:CLAUDE_CONFIG_DIR = "$HOME\.claude-work";  claude @args }

function claudelocal {
    $env:ANTHROPIC_AUTH_TOKEN = "ollama"
    $env:ANTHROPIC_BASE_URL = "http://localhost:11434"
    if ($args.Count -eq 0) {
        claude --model qwen3.6:35b
    } else {
        claude @args
    }
    Remove-Item Env:ANTHROPIC_AUTH_TOKEN
    Remove-Item Env:ANTHROPIC_BASE_URL
}

claudeme og claudework peger hver på sin dedikerede config-mappe og opfører sig ellers som et normalt claude-kald. claudelocal gør lidt mere — den dirigerer binæren mod den lokale Ollama-endpoint, falder tilbage til qwen3.6:35b hvis ingen anden model er angivet, og rydder miljøvariablerne væk på vejen ud, så det næste plain claude-kald ikke ved en fejl stadig peger mod localhost. Samme mønster virker på macOS og Linux som aliasser eller shellfunktioner; variabelnavnene er de samme.

Funktionerne sætter sig fast ved at lægge dem i PowerShell-profilen — notepad $PROFILE åbner (eller opretter) profilfilen, klistr funktionerne ind, gem, og de er tilgængelige i enhver ny shell fra det øjeblik. På macOS og Linux er pendanten ~/.zshrc eller ~/.bashrc.

Første gang man starter claudework mod en tom config-mappe, kommer det normale /login-flow mod den konto, man godkender. Gør det én gang pr. mappe, og opsætningen står.

Hvad bliver isoleret, og hvad gør ikke

Det her er den del, man skal tænke igennem, før man splitter, for grænsen ligger ikke altid, hvor man gerne vil have den. Med separate CLAUDE_CONFIG_DIR-stier har hver mappe sine egne OAuth-credentials, sin egen settings.json, sine egne hooks, skills, agents, MCP-servere og auto-memory. Intet siver på tværs.

Det, der ikke er isoleret, er selve projektets arbejdsmappe. Hvis man cd’er ind i samme repo fra begge shells, ser og redigerer begge Claude Code-instanser de samme filer. Det er som regel det, man vil, men det betyder, at man stadig skal tænke over, hvilken konto man taler med, lige inden man laver en commit.

Den større konsekvens er, at alt, man holder i den globale config-mappe, skal duplikeres for at være tilgængeligt i begge konti. Skriver man en custom skill, installerer en MCP-server eller tuner en hook, bor det i én config-mappe og er usynligt for den anden. Det bliver hurtigt trættende.

At fylde en tom config-mappe op

En frisk Teams-config-mappe starter med ingenting: ingen plugins, ingen MCP-servere, ingen skills, ingen slash-kommandoer, man var blevet vant til at læne sig op ad. Den personlige side har akkumuleret det hele over tid, og der er ingen clone-kommando. Det skal med over i hånden — men inventarsiden er nemmere, end det lyder.

Fra den personlige config, spørg Claude Code, hvad der faktisk er installeret:

# plugins (virker også som /plugin list inde i REPL'en)
claude plugin list

# MCP-servere (eller /mcp inde i REPL'en for live forbindelsesstatus)
claude mcp list

Begge lister er som regel kortere, end man tror. De plugins, der er værd at flytte, er dem man faktisk bruger; de MCP-servere, der er værd at flytte, er dem med rigtige credentials bag sig. Alt det, man har installeret én gang og aldrig brugt, kan blive tilbage.

Så, i en shell hvor CLAUDE_CONFIG_DIR peger på Teams-mappen, installer hver enkelt:

# plugins (marketplace-navnet er en del af installationsargumentet)
claude plugin install <plugin-name>@<marketplace-name>

# MCP-servere — gentag pr. server med den transport og de args, den nu kræver
claude mcp add --transport stdio <name> -- <command>
claude mcp add --transport http  <name> <url>

Til plugins fra community-marketplaces skal man først køre claude plugin marketplace add <repo>, før installationen kan finde navnet. Den fulde syntaks står i plugins-docs og MCP-docs.

Et par ting følger ikke automatisk med:

• Credentials i MCP-servere. OAuth- og API-tokens gemt på en MCP-server hører til den oprindelige konto. Hver remote MCP-server skal autentificeres igen på Teams-siden — som regel en engangs-prompt første gang man bruger den.
• Personlige custom skills og slash-kommandoer. Hvis de ligger som løse filer i ~/.claude/ og ikke som et pakket plugin, skal de kopieres over i hånden. Det er her, man bør stille spørgsmålet, om de i virkeligheden burde ligge i repoet i stedet for — hvilket er næste afsnit.
• Hooks. Hooks i settings.json er lokale til config-mappen. Kopier de relevante poster, men læs dem igennem først — en hook, der gav mening i ens personlige workflow, er måske ikke den, man vil have til at fyre i klient-kode.

Behandl første session i den nye Teams-config-mappe som en opsætningssession, ikke en arbejdssession. Brug tyve minutter på at gennemgå de installerede plugins, plukke dem, man vil have, og gå claude mcp add-linjerne igennem i den nye shell. Efter det føles den nye config-mappe som hjemme.

Løsningen: stop med at lægge alt i den globale config

Det reneste svar er at skubbe projektspecifik konfiguration ind i selve projektet. Skills pr. repo, MCP-server-lister pr. repo, instruktioner pr. repo — det kan alt sammen ligge i projektmappen i stedet for i ~/.claude/ eller ~/.claude-work/. Når det først ligger i repoet, er det ligegyldigt, hvilken konto man taler med. De samme filer indlæses. De samme værktøjer tændes. De samme instruktioner gælder.

Den leverandørneutrale standard, der er ved at fæstne sig, hedder AGENTS.md — en Markdown-fil i roden af repoet, som enhver konform kodeagent læser som sit primære instruktionslag. Den blev doneret af OpenAI til Agentic AI Foundation under Linux Foundation i slutningen af 2025, og den læses indfødt af GitHub Copilot, Cursor, OpenAI Codex, Gemini CLI, Aider, Zed, JetBrains Junie og et dusin andre. Microsoft er Platinum-medlem af foundationen, GitHubs Copilot coding agent tilføjede native support i august 2025, og Microsoft’s ISE-blog anbefaler mønstret eksplicit.

Claude Code læser selv CLAUDE.md snarere end AGENTS.md, men de to er i praksis udskiftelige — symlink den ene til den anden, eller hold dem som to filer, når instruktionerne afviger nok til at gøre en forskel. Pointen er, at en projektlokal instruktionsfil erstatter en bunke duplikeret global opsætning, og den overlever uanset, hvilken Claude-konto (eller lokal model) man starter med i dag.

Parr den med .vscode/mcp.json til tool wiring — et struktureret, maskinlæsbart manifest, som VS Code, Visual Studio 2026 og GitHub Copilot læser direkte. Claude Code bruger .mcp.json i projektroden til samme formål. Tilsammen bærer repoet sit eget værktøjssæt og sine egne instruktioner, og config-mappen pr. bruger pr. konto skrumper ind til credentials og personlige præferencer.

Det er den del af migrationshistorien, de fleste indlæg ikke fortæller. Når skills, MCP-servere og instruktioner først ligger i repoet, holder spørgsmålet om “hvilken Claude-konto sidder jeg på i dag” op med at betyde noget for selve arbejdet. Det betyder kun noget for fakturaen.

Et par ting jeg fandt ud af på den hårde måde

Nogle detaljer, der ikke var indlysende, før jeg løb ind i dem:

API-adgang er sin egen regning. Hverken personlig Max eller en Teams-plads inkluderer API-kredit. Har man bygget tooling, der hitter Anthropic API direkte — agents, batch-jobs, alt udenfor selve Claude-apperne — er det en tredje fakturalinje, eksplicit adskilt fra enhver abonnement.

Teams-pladser findes i to tiers. Standard-pladser inkluderer ikke Claude Code; Premium-pladser gør. Hvis halvdelen af teamet arbejder i Claude Code, handler valg af plads ikke kun om beskedlimit — det handler om, hvorvidt pladsen dækker CLI’en overhovedet. Værd at tjekke før tilmelding.

Training opt-out flipper automatisk på Teams. Personlige konti tillader Anthropic at bruge samtaler til træning, medmindre man fravælger det. Teams-workspaces er default sat den anden vej: ingen træning på jeres data. For klientarbejde betyder det noget, og det er en af de få egentlige grunde til at være på Teams frem for bare at køre alt fra en personlig Max-konto.

Den lokale model er ikke en erstatning, den er en trykventil. claudelocal konkurrerer ikke med cloud-Claude om svært arbejde. Den absorberer volumenarbejdet — omdøbning, refaktorering, scaffolding, tests til noget jeg allerede har designet — som ikke har brug for en frontier-model og ikke bør koste frontier-model-penge. At behandle den som en junior, ikke en ligemand, er den rigtige indstilling.

Man betaler for begge i overgangen. Der er ingen proration, ingen “konverter min Max til en Teams-kredit”-vej i Teams-planen. At opsige personlig Max er en envejs-beslutning — når den først er opsagt, mister man adgangen til den kontos samtaler og Projects. De fleste, jeg har talt med, lader personlig Max køre flere måneder efter onboarding til Teams, bare for at have et sted at række ind efter det gamle arbejde.

Hvad jeg faktisk ville anbefale

Hvis man er ved at flytte til et Teams-workspace, er det her rækkefølgen jeg ville gøre det i:

Beslut, hvad der bliver personligt. Sideprojekter, læring, personlige eksperimenter — det hører nok hjemme på Max for altid. Klientarbejde og alt under fortrolighedsaftale hører hjemme på Teams fra dag ét. Vær ærlig omkring, hvilke Projects der falder i hvilken bunke, før man begynder at kopiere noget.

Prøv ikke at “migrere” — genopbyg selektivt. Brug memory-eksportprompten til den langsigtede kontekst. Brug per-chat-opsummeringsprompten til de få samtaler, der er værd at beholde. Bed hvert Project om at opsummere sig selv til en frø-prompt for sin afløser på Teams-siden. Spring resten over.

Split Claude Code med CLAUDE_CONFIG_DIR fra dag ét. Prøv ikke at dele ~/.claude/ mellem konti og skifte med /login. Det virker en eftermiddag og bider en så i hælen første gang en personlig hook fyrer i en klients repo.

Tilføj en lokal model som tredje bane. Selv én enkelt Ollama-instans med en anstændig kodemodel frigør overraskende meget cloud-kvote og giver et sted at sende det arbejde, der ikke kræver dømmekraft. Sæt den op gennem ANTHROPIC_BASE_URL, og man bruger den samme Claude Code-grænseflade, man allerede kender.

Flyt projektspecifik konfiguration ind i projektet. AGENTS.md (eller CLAUDE.md), .mcp.json, skills pr. repo, hooks pr. repo. Når det først ligger i repoet, opløser migrationsspørgsmålet sig — hvilken som helst konto, hvilken som helst model, hvilken som helst agent der læser standarden, samler de samme instruktioner op. Repoet bliver sandhedskilden, og config-mapperne skrumper til de dele, der virkelig er personlige.

Hold personlig Max i live, indtil man holder op med at række efter den. Det er det eneste sted, de gamle samtaler findes. Sig den op den måned, man opdager, at man ikke har åbnet den i tre uger — ikke før.

Migrationen er ikke kompliceret. Den er bare ikke en migration — det er at køre parallelle konti rent, indtil den personlige stille og roligt holder op med at betyde noget, og at lægge nok i repoet til at det ikke gør en forskel, hvilken konto man startede op med i dag.