Running multiple Claude Code and Codex accounts on one machine

A developer shared a guide for running multiple Claude Code and Codex accounts on a single machine by using separate configuration directories and shell aliases. The approach isolates settings, plugins, and sessions per account, preventing cross-account data leaks and accidental API key usage.

Running multiple Claude Code and Codex accounts on one machine Tip Keep your personal, work, and admin accounts signed in at once. Each command starts the CLI with its own settings folder, so you never switch accounts and never log in twice. What you end up with - One folder per account, so nothing leaks between them. - A short command for each account, which picks that folder for a single launch. - No stray API key reaching Codex when you meant to use your ChatGPT plan. How isolation works how-isolation-works Before you begin before-you-begin Set up profiles set-up-profiles Daily use daily-use Calling this from mobile or a desktop app calling-this-from-mobile-or-a-desktop-app Running sessions in parallel running-sessions-in-parallel Agent-to-agent messaging agent-to-agent-messaging Invoking one CLI from the other invoking-one-cli-from-the-other Command reference command-reference Troubleshooting troubleshooting Operational notes operational-notes When either CLI starts, it picks one folder to work from. That folder holds the account's settings, its plugins, its MCP servers, its hooks, and its past sessions. The command you type picks the folder for that one launch, and it leaves your other terminals alone. | CLI | Selector | Default profile directory | |---|---|---| | Claude Code | CLAUDE CONFIG DIR | ~/.claude | | Codex | CODEX HOME | ~/.codex | php flowchart LR T Terminal -- P plain command T -- W work alias T -- A admin alias P -- CP default profile root W -- CW work profile root A -- CA admin profile root classDef terminal fill: 24292f,stroke: 8b949e,color: ffffff classDef profile fill: 0a3069,stroke: 54aeff,color: ffffff classDef work fill: 116329,stroke: 56d364,color: ffffff classDef admin fill: 9a6700,stroke: e3b341,color: ffffff class T terminal class P,CP profile class W,CW work class A,CA admin Note The ~ in these paths means your home folder. On a Mac, ~/.codex-work is really /Users/yourname/.codex-work . Names that start with a dot stay hidden in Finder, which is normal. This guide assumes macOS or Linux with zsh. If you use Bash, everything works the same, but edit ~/.bashrc instead of ~/.zshrc . echo $SHELL claude --version codex --version Important Only set up profiles for accounts you are allowed to use. A profile keeps things separate on your own machine. It has no effect on what an account is permitted to do, and it will not get you around workspace rules or usage limits. If you have never signed in, do that first with the plain commands. Whatever you sign in as here becomes your default account. claude auth login codex login --device-auth The examples below add two accounts called work and admin . Call yours whatever you like, as long as you use the same names throughout. The Claude Code and Codex halves do not depend on each other, so do one, the other, or both, in whichever order suits you. mkdir -p ~/.claude-work ~/.claude-admin ls -d ~/.claude mkdir -p prints nothing when it works, and it will not complain if the folders already exist. Open your shell configuration: open -e ~/.zshrc Add this block at the bottom: Claude Code: default remains ~/.claude alias claude-work='CLAUDE CONFIG DIR="$HOME/.claude-work" command claude' alias claude-admin='CLAUDE CONFIG DIR="$HOME/.claude-admin" command claude' Why command claude matters command skips over aliases and runs the installed program directly. Without it, an alias can end up calling itself forever. Warning Do not put export CLAUDE CONFIG DIR=... on a line of its own. That applies to every command in every new terminal, and it quietly moves your default account too. An alias sets the folder for one launch and nothing else. source ~/.zshrc claude-work auth login claude-admin auth login Sign in to each one with the account you actually want. If your browser is still signed in from the previous login, sign out first, or open the link in a private window, or keep a separate browser profile per account. claude auth status --text claude-work auth status --text claude-admin auth status --text Each command should name the account you expect. If two of them show the same person, sign out of only the one that is wrong and log in again: claude-work auth logout claude-work auth login Codex works the same way, using CODEX HOME . It creates the folder for you the first time you sign in, so there is nothing to make by hand. Open ~/.zshrc and add: Codex: default remains ~/.codex. Each wrapper removes shell API credentials. alias codex='env -u OPENAI API KEY -u CODEX API KEY -u CODEX ACCESS TOKEN command codex' alias codex-work='env -u OPENAI API KEY -u CODEX API KEY -u CODEX ACCESS TOKEN CODEX HOME="$HOME/.codex-work" command codex' alias codex-admin='env -u OPENAI API KEY -u CODEX API KEY -u CODEX ACCESS TOKEN CODEX HOME="$HOME/.codex-admin" command codex' Important The env -u entries only affect the Codex process being launched. Your shell keeps its variables, and so does everything else on the machine. Reload the aliases: source ~/.zshrc codex-work login --device-auth codex-admin login --device-auth Codex prints a one-time code and a link. Open the link, type the code, and approve it with the account you meant to use. If the browser is already signed in as somebody else, use a private window or a second browser profile. codex login status codex-work login status codex-admin login status Each profile should report Logged in using ChatGPT . Note codex login status confirms the login method and state; it does not print the account email. Keep the browser authorization flows separate and label profile directories clearly. Separate profile roots and separate successful device-auth flows establish the intended isolation. Inspect the three separate Codex roots This shows that each command really does use its own folder. It will not tell you which account is signed in, since the login you completed is what decides that. ls -la ~/.codex/auth.json ~/.codex-work/auth.json ~/.codex-admin/auth.json For current subscription access, plan limits, and workspace controls, see Using Codex with your ChatGPT plan https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan . There is no switch command. Start the account you want: claude default identity claude-work work identity claude-admin admin identity codex default identity codex-work work identity codex-admin admin identity This guide is not CLI-only in practice. A mobile client or a desktop app's session, running on the same host as these aliases, already carries a shell tool — the same bash any CLI agent uses. Every command in this guide is nothing more than a shell command. There is no bridge, skill, or MCP server to build: you set up the aliases once on the host, exactly as described above, then tell the mobile or desktop session to run them there. Run codex-work exec --sandbox read-only -o /tmp/review.txt "<delegation prompt " on the host, then read back /tmp/review.txt for me. That instruction works from a phone or a desktop app exactly as it works typed into a terminal, because it is the same alias, run the same way, by a session that already knows how to call bash . Important This depends on the mobile or desktop session actually running on the host where the aliases live, with shell access to it. A session that only runs in a remote sandbox or on a different machine has no path to your local ~/.zshrc aliases — SSH into the host first, or give the session the full command inline instead of the alias name. But what if I really need this app-to-app — can't you just build me an MCP server or a bridge? No. bash already does this. The mobile client, the desktop app, the CLI — every one of them can already run a shell command on the host, which means every one of them can already run codex-work exec or claude-work -p . An MCP server or a bridge protocol would be a second, worse implementation of a shell call: its own transport, its own auth, its own version skew, its own outage, maintained forever, to reach a command that was already one message away. There is exactly one situation this doesn't cover: a client with no shell access to the host at all. The fix there is ssh , not a protocol. If "tell the session to run the alias" is somehow not a satisfying enough answer and what you actually wanted was a system to design, that's a hobby, not a requirement — and if you can't tell the difference, the agent was never the bottleneck. 🤡 honk honk 🔴 Tip You never log out to change accounts. Open another terminal tab and run a different command. Both sessions keep going, both stay signed in, and neither one bothers the other. Every launch is a separate process. The profile folder keeps logins and settings apart, but it does nothing about the things sessions share: services they both call, workspace resources, or the CLI's own session service. Stay inside what your plan, your organization, and your machine can actually take. Four tabs might look like this: | Tab | Command | Identity | Task | |---|---|---|---| | 1 | claude | default | Personal repository | | 2 | claude-work | work | Work ticket | | 3 | codex-work | work | Second opinion on the same ticket | | 4 | claude-admin | admin | Scheduled maintenance | Different profiles on one machine. Logins and settings are kept apart by design. Several sessions on one profile. Fine where your CLI version and your plan allow it, and each session keeps its own context. Both CLIs on the same task. Useful when you want one agent checking the other's work. Warning Profiles separate settings and accounts . They do nothing about the filesystem . Two sessions pointed at the same working directory will overwrite each other, whichever profiles started them. - Give each session its own Git worktree if they might touch the same repository. - Watch for a shared dev server, database, or port. Profiles do not separate those. - Label your sessions or your terminal tabs. Four identical prompts on screen is how work gets committed from the wrong account. See which sessions are currently running Claude Code, per profile: claude agents --json claude-work agents --json Each command lists only the sessions that belong to the profile you ran it from, with the name, folder, and status of each. Codex: codex agents Codex reports sessions from its shared local app-server daemon. Do not treat this output as a profile-scoped roster. You can hand work from one agent to another in two ways: drop a message into a session that is already running, or start a fresh run. Both CLIs manage both, though they go about the first one quite differently. Codex has a terminal command for it. Claude Code does it from inside the agent, with tools the session already carries. Important Codex authentication and configuration remain selected by CODEX HOME , but codex agents uses a shared local app-server daemon . Do not assume that session discovery or codex queue is profile-scoped, or that sessions are invisible across CODEX HOME roots. Treat the local session roster as shared state and verify the target before sending a message. Running Claude Code sessions can message each other. A session looks up its peers, then sends to one by name using tools it already has. All of that happens inside the agent, so you ask for it in conversation instead of typing a shell command. To see the same list of sessions yourself: claude agents --json Every entry has a name something short, like api-refactor , a sessionId , a working directory, and a status. The name is the address other sessions use. The list belongs to the profile you ran it from. Run it under a different CLAUDE CONFIG DIR and you get a different set of sessions, and a session can only message peers inside its own profile. Note No terminal command drops a message into a running Claude Code session. Anything outside the agent, Codex included, has to start a short Claude run and ask it to carry the message. See Across the two CLIs across-the-two-clis . Codex exposes session discovery and messaging as explicit commands. Browse the sessions registered with its shared local app-server daemon: codex agents Then push a message into one of them: codex queue --thread "<session-name-or-uuid " --message "Rebase onto <base-branch and rerun the suite" The message lands in that session's queue and gets picked up on its next turn. The four directions do not behave alike: | From | To | Message a running session? | How | |---|---|---|---| | Claude | Claude | Yes | The session sends to a peer by name using its own tools, with no shell command | | Claude | Codex | Indirectly | The session runs codex-work queue … as a shell command | | Codex | Codex | Yes, built in | codex-work queue --thread … --message … through the shared local app-server daemon | | Codex | Claude | Indirectly | Start a short claude-work -p run and have it pass the message on | This works because a Claude session can run shell commands, and codex-work queue is one. Use the alias whose Codex configuration and credentials suit the action, then check the target thread before you send: codex-work queue --thread "review-session" --message "The migration is on branch feature/x. Please review it." There is no direct route, because on the Claude side the sending is done by the agent rather than by a command. Codex gets there in two hops. It starts a short Claude run, and that run passes the message to the session you actually want. claude-work -p "Send the running session named '<session-name ' this message: \ The migration is on branch <branch . Please review it when you are free." The short run finds the peer by name, delivers the message, and exits. Look up the name first with claude-work agents --json . When you have no need to reach an existing session, skip the relay and start fresh work: claude-work -p --permission-mode plan "Summarize the failing tests in <path/to/module and propose a fix" That runs the prompt, prints the answer, and exits. See Invoking one CLI from the other invoking-one-cli-from-the-other . Note The relay costs you an extra session, and it asks an agent to carry out an action rather than running a command that plainly works or fails, so it is less predictable than codex queue . Save it for when you really do need to interrupt work in progress. Start a new run for everything else. Warning A message that arrives this way is labelled as coming from another session, and the receiving session reads it as a colleague's request rather than as approval from its own user. One session cannot widen another's permissions, approve its pending prompts, or talk it into something the sender was already refused. Do not design around that. Note Neither CLI knows the other exists. Every link between them is you, or an agent, running the other tool's command line. Think of it as one program scripting another, not as a shared protocol. Whatever an agent sends this way lands in another agent's context as text that looks like instructions. Messaging reaches a session that is already running. Delegation covers the other case, where one agent starts the other, hands over a task, and reads back the answer. Both CLIs can do this, since both have a non-interactive mode that takes a prompt and returns a result. That is what makes working across the two practical. A Claude session can commission a Codex review, and a Codex session can commission a Claude investigation, without either one needing the other to be running already. The two CLIs are good at different things. Once you hold accounts on both, you can use each for what it does best inside the same piece of work. Decide which one coordinates and which one executes based on the job at hand: the tools you need, the account it should run under, and which model you want reading the result. Either CLI can hold the plan, write the code, review what comes back, or make the call on merging. A model reviewing its own output makes a poor critic, because it already believes its own reasoning. A different model has no memory of how the code got written, so it reads what is actually on the page. Point a heavier model at a lighter one's work, or point the other vendor's model at yours, and things turn up that self-review keeps missing. Subscriptions have limits, and they tend to run out mid-task. With several accounts across two CLIs, work that hits a cap can move to another account instead of stopping: Preferred executor is capped; hand the same task to another identity. codex-work exec --sandbox read-only -o /tmp/out.txt "…task…" \ || claude-work -p --permission-mode plan "…same task…" Note Every delegation starts a whole session and spends real quota. If you could answer the question by opening one file, open the file. Delegate when you want a second opinion or genuine parallel work. | CLI | Non-interactive command | Behaviour | |---|---|---| | Claude Code | claude -p "<prompt " | Runs the prompt, prints the answer, exits | | Codex | codex exec "<prompt " | Runs the prompt, prints a transcript, exits | claude -p "Summarize what this package exports" codex exec "Summarize what this package exports" Written plainly like that, both run on your default account. Every example from here on uses the suffixed commands instead. See Delegate as the right identity delegate-as-the-right-identity . Caution -p means opposite things in the two CLIs. In Claude Code, -p is --print , the non-interactive flag itself. In Codex, -p is --profile , which layers a config file and has nothing to do with output. Codex runs non-interactively with the word exec , not a flag. - codex -p "do the thing" -p here means --profile; this is not print mode + codex exec "do the thing" correct Note Watch the word profile , because Codex uses it for a second, unrelated thing. Its --profile flag layers $CODEX HOME/<name .config.toml inside one home directory. In this guide, profile always means a separate account folder chosen by CODEX HOME . The two ideas do not clash, and you can use both together. claude-work -p prints the model's response and nothing else, so it pipes straight into whatever comes next. codex-work exec sends a full transcript to stdout: startup warnings, hook lines, token counts, and the answer somewhere in the middle. Piping that anywhere is miserable. Write the final message to a file instead: codex-work exec -o /tmp/answer.txt "Review the diff on this branch and list concrete defects" cat /tmp/answer.txt | Need | Claude Code | Codex | |---|---|---| | Just the final answer | claude-work -p "…" | codex-work exec -o out.txt "…" | | Machine-readable output | claude-work -p --output-format json "…" | codex-work exec --json "…" | | Constrain the response shape | --output-format json | --output-schema schema.json | | Pick the model | --model <name | --model <name | | Set the working directory | --add-dir <path | -C <path | A delegated run is a real session spending a real subscription. The suffix on the command picks the profile of the CLI you are calling, and it is never inherited from the session doing the calling. Check both profiles before you delegate: claude-work auth status --text codex-work login status From a Claude work-profile session, start a Codex work-profile run: codex-work exec --sandbox read-only -o /tmp/review.txt "Review the staged diff for correctness defects. Do not modify files." From a Codex work-profile session, start a Claude work-profile run: claude-work -p --permission-mode plan "Review the staged diff for correctness defects. Propose changes only; do not modify files." Use the same suffix on both sides of a hand-off. Personal work gets bare claude and codex , administration gets claude-admin and codex-admin . Every example below uses the work aliases. Important Being inside a codex-work session does not make a bare claude call use your work account, and being inside a claude-work session does nothing for a bare codex call either. Name the profile you are calling, every time. Warning A bare claude or codex from inside a work session quietly bills your personal account, and it hands the delegate your personal settings, MCP servers, and credentials. Nobody is watching an agent you left running. Give it the least it needs to finish. Pick a sandbox on purpose: codex-work exec --sandbox read-only -o /tmp/out.txt "Analyze and report; do not modify files" | Sandbox | Grants | |---|---| read-only | Looking, nothing more. The right choice for reviews and analysis. | workspace-write | Editing inside the working directory. | danger-full-access | No restrictions at all. | Narrow the tools, or take away the ones that run commands: claude-work -p --permission-mode plan "Analyze and propose; make no edits" claude-work -p --allowedTools "Read Grep Glob" "Summarize how auth is wired" claude-work -p --restricted "Explain this file" removes Bash and other execution tools | Flag | Grants | |---|---| --permission-mode plan | Reading and proposing only. Every edit and every command still needs your approval. | --allowedTools "<tools " | Only the named tools; every other tool is blocked. | --restricted | Removes Bash, PowerShell, the REPL, and every other tool that runs commands or code, plus WebFetch, and ignores user, project, and local settings files. | Caution Do not reach for --dangerously-bypass-approvals-and-sandbox in Codex or --dangerously-skip-permissions in Claude Code to force a delegation through. A read-only delegate that comes back with a report covers nearly every cross-CLI task. Loosen that only inside a throwaway sandbox you would not mind losing. The other CLI knows nothing about your session . It has not seen your task, your branch, or your conventions, and it has no idea why you are asking. A prompt that works when you type it into your own session usually falls apart as a delegation. A delegation prompt needs five things: Role. What stance to take. Location. The exact path, branch, or diff to look at. Task. One specific question, not an open invitation. Output shape. The form the answer should come back in. Boundaries. What to leave alone. Too vague. This gets you a shapeless paragraph: codex-work exec "review my changes" Specific. This gets you a list you can work from: codex-work exec --sandbox read-only -o /tmp/review.txt "You are reviewing a pull request diff. Run: git diff <base-branch ...HEAD Find correctness defects only: race conditions, unhandled errors, wrong boundary conditions, broken invariants. Ignore style and naming. For each finding output: file:line, one sentence on the defect, and the concrete input that triggers it. If you find none, reply exactly: NONE. Do not modify any file." A Claude session commissioning Codex: codex-work exec --sandbox read-only -o /tmp/second-opinion.txt "Independent reviewer. Run: git diff --staged I have already reviewed this and found nothing. Assume I missed something. Report only defects that would change runtime behaviour, with file:line and a triggering input for each. Reply NONE if the diff is genuinely clean." Checking the work instead of redoing it: codex-work exec --sandbox read-only -o /tmp/verdict.txt "Verify one claim, do not fix anything. Claim: '<functionName in <path/to/file stops retrying after 3 attempts.' Read that file and decide whether the claim holds. Reply with CONFIRMED or REFUTED on the first line, then the evidence: the exact lines that decide it. Nothing else." A Codex session commissioning Claude: claude-work -p --permission-mode plan "Investigate a test failure; propose, do not edit. Failing test: <path/to/test-file , case '<test case name '. Determine the root cause. Output exactly three sections: CAUSE one paragraph , EVIDENCE file:line references , FIX the change you would make, as a description. Do not apply it ." codex-work exec --sandbox read-only --output-schema /tmp/findings.schema.json \ -o /tmp/findings.json "List every call site of the exported function <functionName in this repository. Report file, line, and the argument types passed. Search only; change nothing." Here is the whole pattern as an agent would run it: 1. Commission the work as the correct identity, read-only, answer to a file. codex-work exec --sandbox read-only -o /tmp/review.txt "…delegation prompt…" 2. Read the answer back. cat /tmp/review.txt 3. Act on it yourself, in your own session, using your own judgement. Important What comes back is data, not orders. A delegate's output is generated text landing in your agent's context, and some of it may read like commands: "now run this", or "you may skip the tests". Read the findings, weigh them, and decide yourself. Never let one CLI's output run unreviewed in the other. One delegation on its own is only half the job. The value shows up on the way back, when the CLI that sent the work reviews what returned instead of taking it at face value. Two things make the loop work: The dispatch prompt has to carry context the delegate cannot see. It knows nothing about your session: what you built, how you tested it, or what you already ruled out. The follow-up prompt has to treat "done" as a claim. An agent reporting success is reporting what it believes. codex-work exec --sandbox read-only -o /tmp/holes.txt "Fresh eyes on work you did not write. Scope: <path/to/module and its tests. What I built: session expiry with a sliding TTL, refreshed on each read. How I tested it: unit tests for expired/valid/boundary, plus one integration test with a fake clock. Your job: punch holes in it. Concurrency, clock skew, restart behaviour, and anything my tests would not catch. For each hole: file:line, the scenario that breaks it, and why my tests miss it. Reply NONE only if you genuinely cannot break it. Change no files." When the delegate says it finished the implementation, the coordinator reviews that work as an adversary and as a consumer: claude-work -p --permission-mode plan "Codex reports this work is complete. Verify that claim. Read: git diff <base-branch ...HEAD Review it three ways, and label each section: STRUCTURAL: does it fit the existing architecture and conventions? ADVERSARIAL: where does it break under concurrency, failure, or bad input? CONSUMER: is the public interface usable and honest about what it does? End with VERDICT: COMPLETE or INCOMPLETE, and if INCOMPLETE, the specific work still outstanding. Propose only; apply nothing." Tip Worth remembering on the way back: if the reviewer found real holes, your tests were not good enough. Fix the tests alongside the defect, or the same kind of hole comes back. 1. Build and test in your own session, as usual. 2. Dispatch the heavier or independent model to attack it. codex-work exec --sandbox read-only -o /tmp/holes.txt "…leg 1 prompt…" 3. Read the findings back. cat /tmp/holes.txt 4. Fix what is real. Judge each finding; do not apply them blindly. 5. Send the fixes back for confirmation, not for a fresh opinion. codex-work exec --sandbox read-only -o /tmp/recheck.txt "Recheck only the findings you previously reported in this area, against the current working tree. For each: FIXED, PARTIAL, or UNFIXED, with the line that decides it. Do not raise new findings." Important Step 5 is the one people skip. Run the original open-ended prompt again and you get a fresh pile of opinions rather than a verdict on your fixes. Ask a narrower question the second time than you asked the first. Once the loop runs smoothly, give each leg to whichever model suits it. One arrangement that works: | Leg | Runs on | Why | |---|---|---| | Plan and decompose | Coordinator CLI | It holds the whole task and the merge decision | | Implement | Executor CLI, autonomously | Long unattended runs are what it is good at | | Adversarial review | The other vendor's model | It has no memory of the implementation reasoning | | Verdict and merge | Coordinator CLI | One place decides whether the work is finished | Warning Findings from a review leg are not optional. A loop that turns up defects and then merges anyway costs more than skipping the review, since you paid for it and threw the answer away. Close every finding, or write down why it does not apply. | Goal | Claude Code | Codex | |---|---|---| | Start work profile | claude-work | codex-work | | Start admin profile | claude-admin | codex-admin | | Authenticate work profile | claude-work auth login | codex-work login --device-auth | | Check login state | claude-work auth status --text | codex-work login status | | Sign out locally | claude-work auth logout | codex-work logout | | List running sessions | claude-work agents --json that profile's sessions | codex agents shared local app-server daemon | | Message a running session | Done by the agent, not the shell; from outside, relay via claude-work -p | codex-work queue --thread <id --message "<text " | | Run one prompt non-interactively | claude-work -p "<prompt " | codex-work exec "<prompt " | Swap -work for -admin , or drop the suffix, to reach a different profile. | Symptom | Cause | Fix | |---|---|---| | Alias is not found | The shell config has not been reloaded | Run source ~/.zshrc , or open a new terminal | | Two Claude profiles show one email | The browser reused a login | Sign out, or use a private or separate browser profile, then run that login again | Codex profile reports Not logged in | The device flow never finished for that root | Run that profile's login --device-auth again | | Settings or plugins turn up in the wrong profile | The wrong command started the session | Quit, check the profile's login state, then relaunch with the right alias | | A plugin or MCP server is missing | Profiles share no configuration | Install or configure it while running that profile | | Codex picks up a shell API key | An env -u entry is missing from the wrapper | Restore the full Codex alias block above | | Alias loops or hangs | It is calling itself | End the alias with command claude or command codex | A session is missing from claude agents --json | It belongs to a different Claude Code profile | Run the listing again with the alias that started it | A session is missing from codex agents | It is not registered with the local app server, or the CLI is connected to another server | Verify that the session is running and use the appropriate --remote endpoint if applicable | codex queue reports an unknown thread | The target is not registered with the app server being queried | Confirm the exact session name or UUID with codex agents , then retry against the appropriate local or remote server | | Two sessions overwrite each other's edits | They share a working directory | Give each session its own Git worktree | codex -p "prompt" does something unexpected | In Codex, -p is --profile , not print mode | Use codex exec "prompt" | | A delegated run billed the wrong account | It went out without a suffix | Delegate through the profile alias, such as codex-work exec … | The answer from codex exec is buried in warnings | stdout carries the whole transcript | Write the final message to a file with -o <file , or use --json | Tip When something profile-related goes wrong, work out which command started the session and check that profile's login state before you change any settings. - Configuration and preferences - Local plugin and skill state - MCP registrations and hooks - Session history and transcripts - Login material associated with the selected profile root - The list of running sessions shown by claude agents in Claude Code, and which peers a session can message Note Codex session discovery and message queueing are not listed here: codex agents uses a shared local app-server daemon. Verify the current CLI's behavior before treating any session as profile-specific. Warning A plugin, MCP server, or hook set up in one profile will not appear in another. Configure each profile on purpose. Codex supports ChatGPT-plan access and API-key access. The wrappers above prevent a shell-provided OPENAI API KEY , CODEX API KEY , or CODEX ACCESS TOKEN from being passed into the launched Codex process when the intent is to use ChatGPT sign-in. This is a credential-selection guard, not a billing bypass. Usage limits, credits, and workspace controls follow the signed-in account and its applicable plan or organization. Do not assume that multiple profiles create independent quotas. If a Codex installation previously used an API key and needs to switch to ChatGPT-plan access, OpenAI's current guidance is to update Codex, run codex logout , then start codex and sign in with ChatGPT. Official guidance https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan Optional Claude Code API-key guard Claude Code needs the same wrapper only if your shell exports an Anthropic credential at startup. Check without printing any token: env | grep '^ANTHROPIC ' If that prints something and you meant to use your subscription, add the guard to each Claude alias: alias claude-work='env -u ANTHROPIC API KEY -u ANTHROPIC AUTH TOKEN CLAUDE CONFIG DIR="$HOME/.claude-work" command claude' alias claude-admin='env -u ANTHROPIC API KEY -u ANTHROPIC AUTH TOKEN CLAUDE CONFIG DIR="$HOME/.claude-admin" command claude' In Claude Code, these settings answer two different questions: | Setting | Controls | Question answered | |---|---|---| CLAUDE CONFIG DIR | Identity and profile state | Which account profile starts? | ANTHROPIC BASE URL , ANTHROPIC MODEL | Model backend | Which endpoint and model answer? | You can combine them when you mean to: CLAUDE CONFIG DIR="$HOME/.claude-work" \ ANTHROPIC BASE URL=http://localhost:11434 \ ANTHROPIC AUTH TOKEN=local \ ANTHROPIC API KEY="" \ ANTHROPIC MODEL=<model-name \ command claude Run a global installer from the profile that should own what it writes. It changes that profile's folder, not every profile on the machine. Generated hooks often contain absolute paths, so run installers from a stable checkout rather than a feature branch you plan to delete. - Sign out of that profile: claude-work auth logout codex-work logout - Check the suffix carefully, then remove the folder: rm -rf ~/.claude-work ~/.codex-work - Delete the matching aliases from ~/.zshrc and reload it: source ~/.zshrc Caution rm -rf deletes for good. There is no Trash and no undo. Read the path twice before you press Return, and never let it end up as ~/.claude or ~/.codex , which would wipe your default account's settings and history. Check these commands against your installed CLI versions before relying on them in a managed or production environment.