[BUG] Multi-repo cloud sessions map repos to git remotes incorrectly; `origin` is arbitrary

Bug: multi-repo cloud sessions map repos to git remotes incorrectly; origin is arbitrary

Surfaces: Claude Code on the web / desktop (Windows) — cloud sessions and Routines.
Severity: high. Causes pushes, PRs and issues to land in the wrong repository.

(Repo and owner names below are stubs; the structure is verbatim from a real session.)

Summary

When more than one repository is attached to a cloud task/session/Routine, the
repositories are not represented correctly in the resulting git checkouts. Which repo
becomes origin appears arbitrary:

• Routines: the last repo added in the GUI becomes origin.
• Sessions: less predictable; two repos sharing a name appear to collapse into a

single checkout.

Nothing in the session states which repo is origin or how the others are reachable,
so the agent has no way to notice it is wrong.

Expected

The first repo added is the working repo and becomes origin in the primary checkout.
Additional repos are attached as additional repos — readable/clonable, usable for
issues and code — each with its own checkout and its own correct origin, and never
silently overwriting the primary one. The session should state plainly which repo is
origin.

Actual

Repos in scope per the session prompt:

initech/widgets
octo-dev/ledger      (fork, where feature branches belong)
contoso/ledger       (upstream, production)

Checkouts produced:

/home/user/Widgets   origin = https://github.com/initech/Widgets
/home/user/Ledger    origin = https://github.com/contoso/Ledger

Three repos in scope, two checkouts. The two ledger repos collapsed into one, and
contoso/ledger (production) won origin. No upstream remote exists.

This is actively dangerous: that repo's own contributing docs define origin as the
fork (octo-dev/ledger, which auto-deploys to QA) and upstream as production
(contoso/ledger), with feature branches PR'd to origin/main and promotion to
production being the one flow requiring explicit human sign-off. An agent obeying the
repo's documented rules in this session would push feature branches straight at
production.

The session's branch instructions also list a branch for all three repos, implying
three checkouts that do not exist.

Note the tool scope is correct — GitHub MCP access covers all three. It is the git
checkout/remote mapping that is broken.

Repro

1. Create a cloud task or Routine (desktop or web).
2. Attach two or more repos, including two with the same repo name under different owners.
3. Start the session and run git -C <each checkout> remote -v.
4. Observe: fewer checkouts than repos, and origin set to a repo other than the first attached.

Impact

Repeated real-world incidents: agents pushing branches to the wrong repository and
opening issues in the wrong repository. Recovering from that is manual and, where one
of the repos is production, carries real risk.

Asks

1. Deterministic mapping: first attached repo = primary checkout = origin.
2. Disambiguate repos by owner/name, never by name alone — same-named repos under

different owners must get separate checkouts.

1. Surface it in the session: state which repo is origin and where each other repo is

checked out, so an agent can verify before pushing.

1. Preserve or document additional remotes (e.g. a fork/upstream pair) rather than

dropping them.