Keep Claude Code and Codex Auth Separate on Each Daemon

Claude Code and Codex auth gets messy when every machine is treated like the same machine.

Your laptop may have your personal provider login, your work desktop may have company GitHub access, and a headless machine may have a different repository checkout and model defaults. If an AI coding agent run fails, you need to know whether the problem is the prompt, the branch, the provider login, the Git remote, or the daemon that launched it.

Junction's daemon model makes that boundary explicit. The daemon runs on the machine where your code already lives. Each daemon can keep its own provider auth, GitHub login, and model configuration. The browser or mobile app is the control surface, but the execution environment remains the local machine that owns the repository.

That is useful for trust, but it is also useful for debugging.

Why Auth Boundaries Matter

Claude Code and Codex handle their own provider authentication. Junction should not hide that fact. If the provider CLI is not installed, not logged in, out of quota, or unable to access a model, the right fix is to repair that provider setup on the daemon machine.

The same principle applies to Git:

• A laptop may be authenticated to a personal fork.
• A work machine may push to the company remote.
• A server may have deploy keys or limited access.
• A worktree may have a different branch target.

If those contexts collapse into one generic "agent" label, debugging becomes guesswork.

With daemon-scoped boundaries, you can ask better questions:

• Which machine launched the run?
• Which provider account does that machine use?
• Which GitHub identity owns the branch or pull request?
• Which model or reasoning default is active?
• Which repositories are present on that machine?
• Which daemon should receive the next task?

That is the difference between remote control and remote confusion.

A Practical Multi-Daemon Setup

For a solo developer, a simple setup might look like this:

For a team, the same idea applies by project or environment:

• frontend daemon for UI work,
• backend daemon for API work,
• high-memory workstation for large codebases,
• isolated daemon for risky automation.

Core and Switchboard support unlimited daemon connections, so you can use machine boundaries intentionally instead of squeezing every run through one checkout.

What To Check Before Routing a Task

Before launching Claude Code or Codex through a daemon, check:

1. The daemon is the machine that has the intended repository.
2. The provider CLI works directly on that machine.
3. Git remotes and branch permissions match the task.
4. The model defaults are appropriate for the work.
5. The task does not require files that only exist on another machine.
6. The daemon is online and reachable from the Junction app.

This is especially important before automation. A Switchboard route that turns a Linear issue into a pull request should not guess which machine owns the repository. It should route to the daemon with the right repo, branch policy, provider setup, and permissions.

Example: The Wrong Daemon Problem

Imagine this task:

Fix the failing billing summary test and open a reviewable pull request.

If you route it to the wrong daemon, several things can happen:

• the billing repo is missing,
• the provider CLI is not logged in,
• GitHub cannot push the branch,
• the daemon has old dependencies,
• the model defaults are wrong for the task,
• the agent edits a stale checkout.

None of those are prompt-quality problems. They are environment routing problems.

Junction helps by making daemons visible as first-class connections. The control surface can show which daemon owns the session while the run output, approvals, Git state, and diff review remain attached to that context.

How This Relates To Local-First Development

Local-first does not mean every machine is interchangeable. It means execution stays in the environment you chose.

That environment has:

• local files,
• local tools,
• local credentials,
• local Git state,
• local provider authentication,
• local hardware constraints.

The browser app is there to control and monitor, not to erase those differences. Keeping daemon identity visible lets you use local-first development deliberately.

If you want the architecture behind this, read How the Junction Daemon Keeps AI Agents Local. If you want the multi-machine workflow, read How to Manage Multiple AI Coding Agents Across Machines.

Tradeoffs

Separate daemon boundaries create a little more setup work. You need to install the provider CLI, authenticate it, verify Git, and confirm the daemon can see the repositories it should manage.

That setup is worth doing because it prevents more expensive failures later. A bad daemon choice can waste a provider usage window, create an unpushable branch, or produce a diff against the wrong checkout.

There is also a security tradeoff. Do not give every daemon every credential just for convenience. Route tasks to the machine that should do the work, and keep unnecessary access out of environments that do not need it.

The Habit To Build

Before launching a run, name the daemon in your head:

This task should run on the work desktop daemon because it has the company repo, the right GitHub login, and the provider account for this project.

That one sentence catches many mistakes.

Start with the Junction setup guide to pair one daemon. If you need more daemon connections or open chats, compare the current limits on pricing.