The Junction daemon is the part of Junction that makes local-first agent control possible.
The browser is the surface you see. The daemon is the process on your machine that knows where your repositories live, which agent CLIs are available, what sessions are running, and what changed in Git. When you use Junction to control Claude Code or Codex from a browser or phone, the daemon is the local execution anchor.
That distinction matters. Without a local daemon, a remote control surface tends to become either a cloud sandbox, a raw SSH session, or a hosted chat app that cannot see the exact project state you have on your workstation. Junction takes a different route: keep execution local, then make the control plane reachable.
The daemon is not a cloud workspace
A cloud coding workspace tries to recreate enough of your environment somewhere else. That can be useful for some tasks, but it introduces a source-of-truth problem. Which checkout is current? Which secrets and local services exist? Which branch has the uncommitted diff? Which machine has the provider CLI authenticated?
Junction's daemon avoids that class of problem by running where the code already lives.
The daemon machine can be your laptop, desktop workstation, headless server, or VPS. The important part is that it owns the local project context. Claude Code and Codex execute from that environment. Junction does not need to move your repository into a hosted sandbox for the browser app to become useful.
OpenAI's Codex web docs describe cloud delegation as a model where Codex works in its own cloud environment. Anthropic's Claude Code Remote Control docs describe a local session model where a remote interface can steer work that still runs on the user's machine. Junction's daemon is built for that second kind of local-first control, across the Junction interface.
What the daemon actually does
At a practical level, the daemon is responsible for the work that must stay close to the repository.
It can:
- launch and manage agent sessions,
- stream agent output, tool calls, and status,
- keep track of running, blocked, failed, and completed work,
- expose Git state and diffs,
- handle approvals and stop/start controls,
- manage daemon-specific provider configuration,
- report daemon health,
- connect directly over WebSocket or through Junction's relay,
- and expose an MCP server so agents can manage or query other agents.
The browser app should not be responsible for those things. A browser tab may close, reload, or move between devices. The daemon gives the workflow a stable local process that can keep track of agent state.
The browser is the control surface
Junction's web app is where you supervise the daemon.
That includes the high-value human decisions:
- Is the run still on track?
- Did the agent ask for a risky permission?
- Did the diff match the task?
- Should this continue, stop, or be redirected?
- Is this ready for a pull request?
The browser interface can be desktop-sized or phone-sized. The job is the same: turn raw agent activity into a set of reviewable decisions.
That is why Junction is not just a terminal mirror. A terminal mirror can show text. Junction can show sessions, machine context, approvals, Git state, file changes, and notifications in one workflow-specific surface.
The connection can be direct or relayed
In a local network, a browser can connect directly to a daemon over WebSocket. That is the simplest path when the machine and browser can reach each other.
Remote work is harder because laptops and home networks usually sit behind NAT, firewalls, and changing addresses. Junction supports a relay path for that reason. The relay bridges the connection between browser and daemon so you can reach the control surface without opening inbound ports by hand.
This post is not a replacement for the deeper relay article. The architectural point is narrower: the relay is transport for the control plane. It is not where your agent executes and it is not a cloud copy of your repository.
The daemon still owns the local process. The browser still owns the human interface. The relay helps them talk when direct network access is inconvenient.
Why WebSocket streaming matters
AI coding agents are not request-response tools once the work gets real. A useful run may involve reasoning, file edits, shell commands, permission requests, test output, and follow-up questions.
Polling for that kind of state feels stale. Raw terminal access feels noisy. Junction uses real-time streaming so the control surface can update as the daemon observes agent activity.
That is useful for three reasons.
First, it reduces blind waiting. You can tell whether the agent is investigating, editing, testing, or stuck.
Second, it makes interruptions safer. If Claude Code asks to run a risky command or Codex proposes a change outside the task, you can respond before the run drifts further.
Third, it gives mobile review a narrower job. You do not need to read every token. You need enough live context to decide whether your attention is required.
Provider authentication stays on the daemon machine
Claude Code and Codex handle their own authentication outside Junction. The daemon does not turn Junction into a provider account broker. It launches the tools available on the machine and works with the provider sessions already configured there.
This is important for multi-machine workflows. A laptop daemon, workstation daemon, and VPS daemon can each have different local tools, GitHub login state, and provider configuration. Junction's Core and Switchboard plans support unlimited daemons because that machine-level separation is part of the workflow, not an edge case.
For example:
- your laptop can handle small review and docs tasks,
- your workstation can handle heavier local test suites,
- a VPS can stay online for always-on Switchboard work,
- and each daemon can keep its own local configuration.
The control surface can show those machines together without pretending they are one identical cloud environment.
A practical daemon workflow
Imagine you want Codex to fix a failing test in a branch that has uncommitted local changes.
With a cloud-first workflow, you have to decide whether the cloud environment has enough of that state. Maybe the branch is pushed. Maybe the local fixture is not. Maybe the failing test depends on a database or service only running on your machine.
With Junction, the workflow is local:
- The daemon runs on the machine with the failing checkout.
- You start a Codex session from Junction.
- Codex works inside that local project context.
- Junction streams output and state to the browser.
- If Codex asks for approval, you can approve or deny from the control surface.
- When Codex changes files, you can inspect the diff.
- If the work is good, you move toward a pull request from the same Git context.
The same pattern applies to Claude Code. The provider may differ, but the architecture stays consistent: local execution, remote visibility, human control.
What this architecture does not solve
A local daemon is not magic.
If your laptop is asleep, disconnected, or missing the provider CLI, the browser app cannot make the agent run there. If your project setup is broken locally, the daemon inherits that broken setup. If a task is too vague, local execution will not make it clear. If the agent asks to do something risky, a human still needs to make a judgment.
That is the right tradeoff. Junction is designed to preserve local control, not hide local reality.
When this model is a good fit
The daemon model is especially useful when:
- your repository should stay on your machine,
- the task depends on local services, branches, fixtures, or secrets,
- you want to supervise Claude Code and Codex from more than one device,
- you need Git and diff review in the same control surface,
- you run agents on more than one machine,
- or you want Switchboard to turn structured Linear issues into local agent work.
It is less useful when the task is fully detached from local state and you are comfortable delegating it to a cloud coding environment.
The short version
Junction's daemon keeps the important parts local: the repository, the agent process, provider authentication, Git state, and machine-specific configuration. The web app gives you a browser and mobile control surface for that local work.
That is the architecture behind Junction's product promise: your dev environment, in your pocket, without turning your codebase into a cloud sandbox.
Start with the Junction setup guide to install and pair one daemon. If you need multiple daemon connections or more open chats, compare the current limits on pricing.