How to Organize Multiple Repositories in One Junction Workspace

Multi-Repo Work Needs A Naming System

Running Claude Code or Codex across multiple repositories is useful until every chat title looks the same. A control surface only helps if you can tell which repo, branch, daemon, and task you are looking at.

Junction gives you one browser workspace for agent sessions, live output, terminal context, file browsing, diffs, and Git state. That is helpful, but it does not remove the need to organize the work. If your repositories are scattered across machines and your sessions are named vaguely, you will eventually open the wrong run and approve the wrong thing.

The fix is simple: treat repository organization as part of the agent workflow.

Start With Working Directory Discipline

Every agent run should start in the correct working directory. That sounds obvious, but it is the most common source of multi-repo confusion.

Use predictable paths:

~/work/company-api
~/work/company-web
~/work/company-docs
~/side/project-alpha
~/side/project-beta

Avoid directories named new, test, copy, or tmp for active agent runs. Those names become useless when you are reviewing sessions from a phone.

If a repository needs worktrees, put them under a predictable parent and include the task or branch name in the path. The goal is that a file browser, terminal prompt, or diff header can tell you where you are without extra archaeology.

Name Sessions For Review

Good session names include the repo and the task:

api: fix webhook retry test
web: inspect mobile nav regression
docs: update pricing copy

Bad session names include only the agent, the model, or a vague verb:

claude run
fix bug
new task
codex test

Session names become more important on mobile because screen space is limited. If you have to open three chats to find the right one, the control surface is already slower than it should be.

Use One Repo Per Session

Do not ask one agent session to work across several repositories unless that is truly the task. Cross-repo work is harder to inspect, harder to test, and harder to turn into a pull request.

Prefer:

• One session for api.
• One session for web.
• One session for docs.
• One pull request path per session.

If two repositories must change together, write that into the prompt and review the run as a coordinated change. Otherwise, separate the sessions.

Keep Git State Visible

In a multi-repo workspace, Git state is the accountability layer. Before approving agent work, check:

• Which repository changed?
• Which branch is active?
• Which files are modified?
• Is the diff scoped to the requested task?
• Is there a pull request path?
• Are there unrelated changes already present?

Junction""'s Git and diff views are useful because they put this information near the agent conversation. That matters when you are not at the terminal. The transcript explains what the agent says it did. The diff shows what actually changed.

A Practical Review Routine

For each active repository, keep a small review routine:

1. Open the session and confirm the repo path.
2. Check the branch name.
3. Read the latest agent output.
4. Review the changed files.
5. Decide whether to continue, steer, stop, or move to pull request review.

This routine is short enough to do from a phone but strict enough to catch most wrong-repo mistakes.

Example: Three Repos, Three Runs

Imagine you are maintaining a web app, an API, and a docs site.

Start three separate sessions:

• web: fix sticky footer on mobile
• api: add retry logging to webhook worker
• docs: update setup guide wording

Each session starts in a different working directory. Each has its own branch. Each produces its own diff. You can inspect them from the same Junction workspace, but the review paths do not blend together.

That structure also makes it easier to decide which tasks belong on which machine. The web repo might stay on your laptop because you need visual inspection. The API repo might run on a faster workstation. The docs repo might be fine on a VPS.

Tradeoffs

More structure means a little more setup. You may spend an extra minute naming sessions and checking paths. That minute prevents the much more expensive failure mode: discovering that an agent edited the wrong checkout or mixed unrelated changes into a pull request.

The other tradeoff is that multi-repo work can make the Free plan feel tight. Free gives you core app access with one saved daemon connection and two open chats. If you routinely keep several repositories active, Core""'s unlimited daemons and open chats will fit the workflow better.

Where Junction Fits

Junction works best when the repo structure is clear. The browser gives you the surface for live output, file browsing, terminal context, Git state, and diffs. Your naming and directory discipline make that surface easy to use.

If you are building the habit, start with one repository and the setup guide. Then add a second repo only after the first one is easy to inspect. For deeper context on the interface pieces, read about using the terminal and file browser as an agent control surface.