Configure Switchboard Route Settings for Team and Repo Routing

Switchboard route settings answer a practical question: when a Linear issue is ready for an AI coding agent, which machine, repository, agent, model, branch policy, and automation rule should handle it?

That question matters once a team moves past one-off agent chats. A single developer can manually choose a local repo, start Claude Code or Codex, and review the result. A team needs repeatable routing. Backend issues may belong on a workstation with the right services installed. Documentation issues may run on a lighter machine. High-risk work may need plan mode before edits. Some teams may want automatic pickup from a specific Linear status, while others may prefer manual starts.

Junction's Switchboard plan exists for that operational layer. It adds Linear automation to the same local-first control surface: the daemon still runs on your machine, agents still execute where the code already lives, and Switchboard coordinates issue-to-pull-request work through configured routes.

What a Switchboard route controls

A route connects a Linear team and repository workflow to a specific execution setup.

In Junction, route settings can cover:

• The daemon that should run the work.
• The agent provider for that route.
• The default model and thinking level when available.
• Whether new runs should start in plan mode.
• The Linear status that enables automatic pickup.
• The daemon interruption policy for restart or offline cases.
• Tracker project metadata.
• Git remote and base branch defaults.
• Branch prefix and new-branch naming behavior.
• Concurrency limits and polling cadence.
• Branch-selection policies when Linear issues already have branch or pull request context.

That is a lot of configuration, but it is not configuration for its own sake. It is how teams keep automation predictable.

Start with the daemon

The daemon is the machine boundary. It owns local repo access, provider sign-ins, GitHub CLI login, model configuration, local dependencies, and the actual agent process.

That makes daemon selection the first route decision. If the selected daemon cannot access the repository, Switchboard cannot reliably launch the run. If the daemon is offline, route status may remain stale until it reconnects.

Use a route-specific daemon when:

• The repository requires local services or credentials available only on one machine.
• The work is heavy enough to belong on a workstation or VPS.
• A team should not run work on a personal laptop.
• Different repos require different provider accounts or GitHub identities.

Use a shared daemon when:

• The repos share the same setup.
• The team wants one always-on machine for automation.
• The route volume is low enough that concurrency limits are sufficient.

Core and Switchboard plans support unlimited daemons. Free is intended for core app access with one saved daemon connection and two open chats, so it is useful for learning the workflow but not for multi-route automation.

Pick the agent, model, and plan mode deliberately

Switchboard route settings let teams choose whether Claude Code or Codex should handle the route. The right answer depends on the codebase, team habits, provider account setup, and the kind of work being automated.

Model and thinking defaults make the route more predictable. A team can pin a stronger model for high-risk platform work, leave another route on provider defaults for lighter edits, and keep those choices attached to the repository workflow instead of asking every operator to remember them.

Plan mode is the safety lever. Claude Code's permission documentation describes plan mode as a mode where Claude can analyze but not modify files or run commands. Junction exposes plan mode in manual chats and route settings so teams can start higher-risk runs with an upfront planning pass. In Switchboard routes, Claude Code can start in plan mode and return to execution after plan approval; Codex routes can also begin with a planning phase before moving into execution.

Use route-level plan mode for:

• High-risk repositories.
• Routes that touch migrations, auth, billing, or shared libraries.
• Teams that want a human to approve the implementation shape before edits.
• Issues that often need clarification before execution.

Turn it off for:

• Low-risk documentation or copy updates.
• Highly constrained issues with strong tests.
• Manual runs where the operator will supervise from the start.

Connect automation to a specific Linear status

Linear's GitHub integration docs describe how issues, branches, commits, and pull requests can stay connected to development work. Switchboard adds a different layer: it can watch selected Linear statuses and pick up matching issues for agent execution.

That is why the watched status should be explicit. "Ready for agent" is usually better than "Todo." It tells humans and automation the same thing: this issue has enough detail, the route is configured, and an agent can start.

A healthy route might use statuses like:

• Ready for agent
• Needs implementation
• Agent queue
• Automation approved

Avoid statuses that mix unfinished triage with executable work. If the issue still needs product decisions, design review, or acceptance criteria, do not route it into automation yet. Write the issue better first. The guide on writing Linear issues ready for AI agent automation covers that earlier step.

Set Git defaults before the first automated run

Branch and remote defaults are easy to ignore until the first bad pull request appears.

Switchboard route settings should make these decisions explicit:

• Which remote should receive branches and pull requests?
• Which base branch should new work target?
• What branch prefix should distinguish Switchboard work?
• Should the route use Linear's branch, auto-generate a new branch, or ask?
• What should happen when there are multiple candidate branches or pull requests?

GitHub's merge-conflict docs are a useful reminder that conflicts must be resolved before a pull request can merge, and complex conflicts often need local resolution in a clone. For AI-agent automation, the best way to reduce conflict cleanup is to start with clear branch rules and avoid running unrelated work on the same branch.

Junction's existing worktree model also helps here. Switchboard can create isolated agent workspaces so each issue gets its own branch and working directory, reducing the chance that one agent run overwrites another.

Use concurrency as a quality control

Concurrency settings are not just about speed. They also protect the repo, review queue, and provider limits.

A route with too much concurrency can create:

• Competing pull requests against the same files.
• More review work than the team can absorb.
• Provider rate-limit pressure.
• Harder debugging when several agent runs fail at once.
• Branch conflicts that could have been avoided.

Start conservatively. For many teams, one active run per repository route is a sensible default. Increase concurrency only after the issue quality, tests, review process, and conflict handling are stable.

A practical route setup example

Imagine a team wants Switchboard to handle small backend maintenance issues.

The route might look like this:

Setting	Choice
Linear team	Platform
Repository	api-service
Daemon	Always-on workstation with local services configured
Agent	Codex
Model	Provider default or pinned route model
Plan mode	On for backend changes
Watched status	Ready for agent
Base branch	main
Branch prefix	sb/platform-
Concurrency	1
Branch policy	New branch unless a single approved branch is already attached

That configuration is specific enough to automate. It still keeps review in the loop: the agent runs locally, output streams through Junction, the diff can be inspected, and the pull request can be reviewed before merge.

Tradeoffs to decide up front

Switchboard route settings create leverage, but they also encode team policy. Do not treat them as a one-time admin form.

Review the route when:

• A repo changes its default branch.
• A daemon moves to a new machine.
• Provider defaults change.
• The team changes its Linear workflow statuses.
• The route starts producing too many conflicts.
• Reviewers cannot keep up with generated pull requests.

Also be honest about automation readiness. If the team cannot write clear issues, does not have useful tests, or has no review owner, route settings will not fix that. They will only make bad inputs move faster.

Where Switchboard fits in Junction pricing

Switchboard is the $15/month plan. It includes everything in Core plus Linear automation, issue-to-pull-request workflows, route settings, and 24/7 automated runs. Core is $10/month for unlimited daemons and open chats without Linear automation. Free includes core app access, one saved daemon connection, and two active/open chats.

If you are still validating manual agent control, start with the setup guide and a normal chat. If you already know which Linear teams and repositories should become agent-run workflows, compare the plan limits on pricing and configure one route before scaling across the workspace.

Route settings checklist

Before enabling automatic pickup, confirm:

• The selected daemon is online and can access the repo.
• Claude Code or Codex is configured on that daemon.
• The route has a clear provider and model default.
• Plan mode is enabled for high-risk work.
• The watched Linear status means "ready to execute."
• Git remote, base branch, and branch prefix are correct.
• Concurrency is low enough for the review process.
• Someone owns reviewing the generated pull requests.

Switchboard works best when routing reflects how the team already wants work to flow. Start with one repository, one team, and one watched status. Tune the route after a few real runs, then expand.