Separate The Execution Boundary First
If you use Claude Code or Codex for both personal and work repositories, the cleanest boundary is not a folder name. It is a daemon boundary.
A Junction daemon runs on a machine and manages the local agent processes on that machine. That machine has its own provider authentication, GitHub CLI login, model configuration, repositories, and environment variables. If personal and work projects share all of those things, it becomes harder to reason about where a session should run and which credentials it can see.
Separating personal and work daemons makes the workflow easier to inspect. You know which machine owns which repos. You know which account is logged in. You know which browser connection should be used for each run.
This is not only an auth article. It is an operating policy for people who move between personal projects, client work, and company repositories in the same week.
What To Separate
At minimum, separate these layers:
- Repositories.
- Claude Code and Codex authentication.
- Git identity and GitHub CLI authentication.
- Environment variables and secret files.
- Default working directories.
- Prompt templates and repo instructions.
- Switchboard routes, if work automation is enabled.
- Notification and approval habits.
- Offboarding or machine-retirement steps.
This is not about distrust of the agents. It is about making the operating model obvious. When an agent is about to edit a work repo, you should not have to wonder whether it is using the same daemon that also has side-project credentials and experimental config.
A Practical Two-Daemon Model
For many developers, the clean setup is:
| Daemon | Repositories | Provider auth | Best use |
|---|---|---|---|
| Personal daemon | Side projects, experiments, private repos | Personal Claude Code or Codex login | Fast iteration, experiments, learning |
| Work daemon | Company repos and tools | Work-approved provider and GitHub login | Team workflows, PRs, Switchboard routes |
The machines can be different physical devices, or they can be separate environments on machines you control. What matters is that the runtime state is not casually mixed.
If you are using Junction Free, one saved daemon connection is enough to start with one side. If you need both personal and work daemons saved and active, Core is the right plan boundary because it includes unlimited daemons and open chats.
Git Identity Matters
Provider auth is only part of the story. Git identity matters too.
Before trusting a daemon with work pull requests, check:
git config user.name
git config user.email
gh auth statusAlso confirm the remotes point to the expected organization. A personal daemon should not accidentally create a branch in a work repository, and a work daemon should not publish commits with your personal email if your team requires a company identity.
Junction can show you the sessions and Git state, but it is still worth fixing the machine defaults before agents start creating reviewable work.
How To Route Work
Use a simple routing rule:
- Personal repo means personal daemon.
- Work repo means work daemon.
- Mixed or ambiguous repo means stop and decide before launching.
- Automation belongs only on the work daemon if the workflow is a team workflow.
That sounds obvious, but it prevents a lot of accidental context leaks. The risk is not just secret exposure. It is also confusing review history, wrong remotes, mismatched branch names, and agent sessions that are hard to explain later.
If you use Switchboard, make the route explicit. Team and repository routing should point to the daemon intended for that work. Do not let automation choose from a vague pool of machines unless every machine in that pool is allowed to work on the same repos.
For client work, add one more rule: the daemon boundary should match the contractual boundary. If two clients should never share credentials, logs, or working directories, they should not share an agent daemon casually.
What To Do With Shared Tools
Some tools are genuinely shared. Node.js, Git, package managers, and test runners can live on both daemons. Shared does not mean identical, though. Keep versions documented per repo. A personal daemon can be more experimental. A work daemon should match team expectations.
Repo instruction files should also stay with the repo. If your work project uses durable instructions for Claude Code or Codex, keep those instructions in source control where appropriate. Do not rely on memory from a personal session to guide work automation.
Tradeoffs
Separate daemons add friction. You may install dependencies twice, authenticate twice, and maintain two sets of machine updates. That is the cost of a clearer boundary.
The alternative is worse once the workflows become serious. A single blended daemon makes it easy to start fast but harder to explain what happened when something goes wrong. For agentic coding, auditability and review context matter.
The boundary should fit the risk. A hobby repo and a throwaway prototype can share a machine. A company monorepo, production credentials, and Switchboard automation deserve a cleaner lane.
The strongest signal that separation is needed is not company size. It is consequence. If the wrong daemon touching the wrong repo would create an access, review, or client-boundary problem, split it.
Start With A Naming Habit
Name daemons and sessions so the boundary is visible at a glance. Use names like personal-macbook, work-workstation, or team-vps. Avoid cute names that hide the purpose of the machine.
Then start one small run on each side and confirm the output, Git identity, and available repositories are exactly what you expect.
For setup details, use the Junction setup guide. For the point where one saved daemon is no longer enough, compare Free, Core, and Switchboard on the pricing page.