Set Up Junction for Claude Code and Codex

If you are looking for a Junction setup guide, the important idea is simple: Junction does not move your repository into a hosted coding workspace. You run a daemon on the machine that already has your projects, terminals, Git state, and agent CLIs. The Junction app becomes the browser and phone-friendly control surface for that local machine.

That is why setup is different from installing another editor extension. The first goal is not to rebuild your development environment somewhere else. The first goal is to connect a web control surface to the environment you already trust, then use it to watch and steer Claude Code or Codex while execution stays local.

This guide explains the shape of that first setup: what needs to be installed, what the daemon does, how the browser connects, and what to try for your first real agent run.

What Junction adds to a local agent workflow

Claude Code and Codex already have their own local workflows. Claude Code has a Remote Control path for continuing local sessions from a phone, tablet, or browser, and Anthropic describes that model as a local session with the remote surface acting as a window into it. You can read the official explanation in Claude Code Remote Control.

Codex also has a local CLI. OpenAI describes Codex CLI as a coding agent that runs locally from your terminal, can read, change, and run code in the selected directory, and is installed with npm i -g @openai/codex. The current docs are at Codex CLI.

Junction sits around those local agent workflows. It gives you one browser interface for:

• live agent output,
• active and completed sessions,
• approval decisions,
• stop and start controls,
• file and diff review,
• Git and pull request flow,
• push notifications,
• and more than one daemon when you have multiple machines.

The product is deliberately web-first. You can open Junction from a desktop browser, tablet, or phone. Modern web apps can be installed from supporting browsers as app-like experiences, and MDN's PWA installability guide explains the broader browser model behind that pattern.

Before you install anything

Set up Junction on the machine where your agents should actually run. For most developers, that is a laptop, workstation, or always-on dev box that already has the repository checked out.

You need:

• Node.js 20 or newer,
• npm 10 or newer,
• GitHub CLI installed and authenticated if you want Git and pull request workflows,
• Claude Code or Codex installed and authenticated on the daemon machine,
• a browser on the device you want to use as the control surface.

Junction does not manage your Claude Code or Codex credentials for you. The agent provider handles its own authentication. That is an important boundary: Junction controls the session surface, but the agent still runs as the tool you already installed on your own machine.

Step 1: install the Junction daemon

Install the Junction launcher on the machine that owns the code:

npm install -g @junctionpanel/junction-daemon

The daemon is the local process that manages agent sessions. It knows about the machine's working directories, available agent CLIs, Git state, and runtime environment. The browser does not become the runtime. The browser connects to the runtime.

That distinction is the reason Junction is useful for serious coding work. Your repo can stay in the same checkout you use every day, with the same package manager, local services, config files, and shell tools.

Step 2: run onboarding

Start onboarding from the daemon machine:

junction onboard

Onboarding initializes the daemon, starts it in the background, and gives you a pairing flow for the Junction app. The exact pairing details may change as the product evolves, but the job is stable: connect the daemon that can run agents to the browser app that will control them.

When the daemon is paired, Junction can show that machine as a saved connection. On the Free plan, you get one saved daemon connection and two active or open chats. Junction Core expands that to unlimited daemons and open chats. Switchboard adds Linear automation for issue-to-pull-request workflows. If you are deciding which limit matters for your team, use Junction pricing after you finish the first setup.

Step 3: confirm the agent CLIs work locally

Before using Junction as the control surface, make sure the underlying agent works directly on the daemon machine.

For Claude Code, run the Claude Code CLI in a project you trust and confirm the provider login is complete. For Codex, run:

codex

The first run should guide you through sign-in if needed. OpenAI's Codex CLI docs also describe the install, run, and upgrade flow for current versions.

Do not skip this step. If the agent itself cannot authenticate or run in the terminal, Junction should not hide that problem. Fix the provider setup first, then use Junction to supervise it.

Step 4: start with one small task

Your first Junction task should be intentionally boring. Pick something bounded, easy to verify, and safe to stop.

Good first prompts look like:

Read the validation tests for the pricing page and summarize the current coverage.

Find the docs page that explains the setup command and suggest one wording improvement. Do not edit files yet.

Inspect the failing unit test output I pasted and propose a fix before making changes.

The point is not to prove the agent can do everything from your phone on day one. The point is to prove the control loop:

1. The daemon starts a local agent session.
2. Junction streams the session state into the browser.
3. You can read output from another device.
4. You can approve, redirect, or stop the run.
5. You can review the resulting diff before treating it as done.

Once that works, increase the complexity.

What to check from your phone

A phone is not a replacement for a full code review station. It is useful because many agent decisions are small and time-sensitive.

From mobile, focus on:

• whether the run is still active,
• whether the agent is waiting for input,
• whether a command failed,
• whether the task has drifted from the prompt,
• whether the agent touched the files you expected,
• and whether the next step is safe enough to continue.

For deeper reading, wait until you are back at a desktop. Junction's mobile workflow is strongest when you use it to keep runs moving, catch bad direction early, and avoid babysitting a terminal.

Local-first does not mean disconnected

The most common misunderstanding is that local-first agent control means you can only use the tool on the same machine. Junction separates execution from supervision.

The daemon runs where the code lives. The web app gives you a control surface from another browser. The same design makes it practical to use a phone while the laptop or workstation does the actual work.

That model is different from a cloud sandbox. Cloud Codex can run background tasks in OpenAI-managed environments, as OpenAI explains in the Codex web docs. That can be useful for some workflows. Junction is aimed at the other case: you want the agent to use the machine, repo, local tools, and credentials you already maintain.

Common first-setup mistakes

The first mistake is installing the daemon on the wrong machine. Install it where the code and agent CLIs live, not just wherever you happen to have a browser open.

The second mistake is assuming Junction can fix provider authentication. It cannot and should not. Claude Code and Codex handle their own login, subscription, and API key behavior.

The third mistake is starting with a risky edit. Begin with read-only work or a tiny change. A working control loop matters more than an impressive first prompt.

The fourth mistake is treating the phone as the whole development environment. Use mobile for status, approvals, short replies, and deciding whether a task should keep running. Use desktop review for larger diffs and ambiguous architecture calls.

A simple first-day workflow

Here is a realistic first-day setup:

1. Install Junction on your laptop.
2. Run junction onboard.
3. Pair the Junction app.
4. Confirm Claude Code or Codex works directly in the terminal.
5. Start a read-only investigation task from Junction.
6. Open Junction from your phone.
7. Watch the output stream and wait for the agent to summarize findings.
8. Send one follow-up instruction.
9. Stop the run or let it finish.
10. Review any changes before you trust the result.

That flow exercises the pieces that matter without creating unnecessary risk.

Where to go next

Once one daemon and one agent workflow feel solid, decide whether you need more capacity. A single developer can stay on the Free plan while testing one saved daemon connection and two active or open chats. Core is the cleaner fit when you want unlimited daemons and chats. Switchboard is for teams that want Linear automation and issue-to-pull-request runs.

Start with the Junction setup guide and get one daemon paired. After that, compare Junction pricing if you need more daemons, more open chats, or Switchboard automation.