Claude Code onthoudt maar één login tegelijk. Zo draai je er meerdere.

Er is een moment dat vrijwel iedereen meemaakt die Claude Code zowel voor werk als voor eigen projecten gebruikt. Je rondt een werksessie af, schakelt over naar een zijproject en beseft dat de agent nog steeds is ingelogd op het account dat je werkgever betaalt. Dus log je uit, log je opnieuw in met je eigen account, en een half uur later mag je hetzelfde in omgekeerde richting doen.

Die lus is geen ontbrekende functie. Het is een gevolg van waar Claude Code zijn login bewaart, en zodra je weet waar dat is, wordt meerdere accounts naast elkaar draaien een configuratiedetail in plaats van een workflowprobleem.

Eén omgevingsvariabele bepaalt welk account actief is

Claude Code bewaart inloggegevens niet in een database of in een keychain-item per profiel. Het leest alles wat het nodig heeft uit één map: inloggegevens, sessiemetadata en de geschiedenis per project.

Die map is waar CLAUDE_CONFIG_DIR naar wijst. Stel je die variabele nooit in, dan is het ~/.claude.

Dit is het hele mechanisme, en het heeft een handige eigenschap: omdat een account een map is en geen globale instelling, betekent twee accounts hebben simpelweg twee mappen hebben. Er wordt niets tussen gedeeld. Beide blijven onbeperkt ingelogd, en geen van beide weet dat de ander bestaat.

De naïeve versie werkt dus gewoon:

# persoonlijk
CLAUDE_CONFIG_DIR=~/.claude claude

# werk
CLAUDE_CONFIG_DIR=~/.claude-work claude

Voer één keer /login uit in de tweede, en je hebt twee actieve accounts op één machine.

Waar de shell-aanpak begint te wringen

De versie van twee regels hierboven is echt prima als je één terminal tegelijk opent en gedisciplineerd bent. Ze houdt om drie redenen op prima te zijn, en die redenen versterken elkaar.

De variabele geldt per proces, niet per machine. Elke nieuwe terminal, elk nieuw paneel, elke shell die in je editor is geïntegreerd start vanaf de standaardwaarde uit je profiel. Exporteer hem in .zshrc en je hebt het probleem alleen verplaatst: nu is het andere account degene die je steeds vergeet.

Niets vertelt je welk account actief is. Claude Code toont het account niet in zijn prompt. Als je twee terminals open hebt en één daarvan draait op het werkaccount, zien ze er identiek uit. Het moment waarop je het merkt is meestal het moment waarop je de facturatie bekijkt.

Het overleeft parallellisme niet. De interessante opstellingen draaien meerdere agents tegelijk, op meerdere projecten. Zodra je voorbij twee gelijktijdige sessies bent, is onthouden welk paneel met welke variabele is gestart geen kwestie van discipline meer, maar een ontwerpprobleem.

De oplossing is niet nog meer shell. De oplossing is stoppen met die beslissing te nemen op het moment van starten, en het account koppelen aan wat het werkelijk bepaalt: het project.

Koppel het account aan het project, niet aan de terminal

Wat je meestal wilt is een regel, geen commando. Zoiets als: de repository van deze klant draait altijd op het account van deze klant. Zodra die regel bestaat, hoeft niemand meer iets te onthouden.

Dat netjes doen betekent het account in een vastgelegde volgorde bepalen, want de regel heeft uitzonderingen nodig. Een standaard voor het hele project klopt meestal, maar één specifieke agent moet misschien ergens anders draaien: een wegwerpexperiment op een testaccount, of een review-agent op een seat met een groter quotum.

Van boven naar beneden gelezen wint de eerste regel die van toepassing is. Een agent-override verslaat het account dat op projectniveau is vastgezet. Dat projectniveau verslaat wat je als algemene standaard hebt ingesteld. Is er nergens iets geconfigureerd, dan kom je uit op ~/.claude, precies wat een verse installatie sowieso al doet. Die laatste terugval telt: het betekent dat je dit aan een bestaande opzet kunt toevoegen zonder dat er iets verandert, totdat je expliciet iets vastzet.

Dit is het model dat AgentsRoom implementeert. Elk account is een beheerde map, het inloggen gebeurt in de app in plaats van in een shell, en de bovenstaande volgorde draait wanneer een agent start, waarbij CLAUDE_CONFIG_DIR alleen op dat proces wordt gezet. Gebruik je al een externe switcher zoals CCS, dan kun je een account naar een bestaande profielmap laten wijzen in plaats van opnieuw in te loggen.

Hetzelfde probleem bestaat bij Codex, met een andere variabele

Draai je meer dan één provider, dan loop je hier twee keer tegenaan. De vorm is identiek, de variabele niet, dus een switcher die voor de een is gebouwd dekt de ander niet. De Codex-kant documenteren we apart in multi-account voor Codex, inclusief wat er anders is in de inlogflow.

Het algemene punt is het waard om één keer uit te spreken: accountisolatie is een mechanisme per provider. Elke tool die beweert dit globaal af te handelen, verpakt ofwel elke provider afzonderlijk, of ondersteunt er maar één.

Weet welk account daadwerkelijk tokens verbrandt

Accounts scheiden is maar de helft van de reden waarom mensen dit doen. De andere helft is weten waar het verbruik terechtkomt, zeker wanneer een klant betaalt.

Dit is het deel dat stilletjes stukgaat met de shell-aanpak. Verbruiksmeters die alleen naar ~/.claude kijken, rapporteren te weinig zodra een agent ergens anders draait, en de cijfers zien er plausibel genoeg uit dat niemand het wekenlang doorheeft. Een meter die accountbewust is, moet over elke geconfigureerde map itereren, niet alleen over de standaardmap.

Wil je cijfers per account en per sessie, dan hebben we de meetkant behandeld in hoe je Claude Code-tokengebruik controleert, en het live overzicht staat op de pagina over tokengebruik.

Waar dit niet voor bedoeld is

Eén verduidelijking, want de vraag komt op en verdient een recht antwoord in plaats van stilzwijgen.

Alles hierboven gaat over het scheiden van accounts die al legitiem bestaan. Een seat die je werkgever betaalt en een persoonlijk abonnement dat je zelf betaalt zijn twee verschillende commerciële relaties, en die zonder kruisbesmetting op één machine houden is een reële, doodgewone behoefte. Dat geldt net zo goed voor het doorbelasten van de tokens van een klant aan die klant, en voor het weghouden van een experimenteel account bij een productieaccount.

Extra accounts aanmaken om de capaciteitslimieten van je abonnement te omzeilen is iets heel anders, en daar is het gebruiksbeleid op gericht. Het mechanisme dat hier beschreven wordt maakt dat niet acceptabel, en een tool die dat zou automatiseren, zou je helpen een overeenkomst te schenden die je zelf hebt getekend. Bestaat je tweede account omdat iemand anders ervoor betaalt, dan sta je op vaste grond. Bestaat het om een rate limit te resetten, dan niet. Het gebruiksbeleid van Anthropic is de referentie, niet dit artikel.

Vragen die mensen echt stellen

Kan ik twee Claude Code-accounts op dezelfde computer gebruiken?

Ja. Claude Code leest zijn inloggegevens, sessiemetadata en projectgeschiedenis uit de map waar CLAUDE_CONFIG_DIR naar wijst, standaard ~/.claude. Laat die variabele naar een tweede map wijzen en log daar in, en je hebt twee onafhankelijke accounts op dezelfde machine. Er wordt niets gedeeld tussen de twee mappen, dus beide blijven tegelijk ingelogd.

Hoe wissel ik van Claude Code-account zonder uit te loggen?

Je logt helemaal niet uit. Uitloggen en opnieuw inloggen hergebruikt dezelfde map, dus je verliest de eerste sessie om de tweede te krijgen. In plaats daarvan geef je elk account zijn eigen configuratiemap en kies je ertussen door CLAUDE_CONFIG_DIR te zetten wanneer je de CLI start. Beide inloggegevens blijven geldig op schijf, en wisselen kost niets.

Waar slaat Claude Code zijn login op?

In de map waar CLAUDE_CONFIG_DIR naar wijst, en dat is ~/.claude tenzij je het verandert. De inloggegevens zelf belanden in een .credentials.json bestand in die map, naast de sessiemetadata en de geschiedenis per project. Die ene map is het hele account, en dat is precies wat het verwisselen ervan een schone wissel maakt in plaats van een hack.

Kunnen twee agents tegelijk op twee verschillende Claude-accounts draaien?

Ja, zolang elk agentproces zijn eigen CLAUDE_CONFIG_DIR in zijn omgeving krijgt. De variabele wordt per proces bij het starten gelezen, niet globaal, dus twee agents die met twee verschillende waarden worden gestart draaien parallel op twee verschillende accounts. Dit is wat een werkproject en een persoonlijk project bruikbaar maakt in hetzelfde venster.

Is het in strijd met de voorwaarden van Anthropic om meer dan één Claude-account te hebben?

Aparte accounts aanhouden voor aparte doeleinden is doodnormaal: een seat die je werkgever betaalt en een persoonlijk abonnement dat je zelf betaalt zijn twee verschillende commerciële relaties. Waar het gebruiksbeleid op mikt, is het aanmaken van accounts om de capaciteitslimieten van je abonnement te omzeilen. Bestaat je tweede account omdat iemand anders ervoor betaalt, dan sta je op vaste grond. Bestaat het om een rate limit te resetten, dan niet. Het gebruiksbeleid van Anthropic is de referentie.

De korte versie

Claude Code slaat een account op als een map, en CLAUDE_CONFIG_DIR bepaalt welke actief is. Twee mappen betekenen twee accounts, permanent ingelogd, zonder dat er iets tussen gedeeld wordt.

De shell-versie hiervan werkt tot je meer dan één terminal open hebt. Daarna wil je dat het account een eigenschap van het project is, met een override per agent voor de uitzonderingen, zodat de juiste inloggegevens bij het starten worden meegegeven en niemand iets hoeft te onthouden.