Single-repo-per-session makes web sandboxes unusable for real multi-repo development

Summary: Claude Code on the web hard-binds a session to one repository, with no supported path to work across several. For anyone who works across multiple repos — i.e. most professional developers — the web sandboxes are simply non-functional. Assuming a single-repo workflow is the default is out of step with how modern software is actually built.

Real-world usage this breaks: I routinely work across dozens of repositories, varying by project. This particular project currently spans six and will likely grow:

• todotik-infra (the attached repo)
• todotik-ops
• todotik-release
• todotik-sdk
• todotik-web
• todotik-common

These reference each other constantly (the infra repo's own docs assume ../todotik-ops as a sibling). Operating on one in isolation is not a real workflow — it's a toy.

What actually happens:

• The session clones the one attached repo. Cloning siblings in the setup script fails with a bare 403 from the internal git proxy.
• It fails even though my own PAT — present in the environment for months, valid from every other machine I use — has full access to all of these repos. Git config injects url.http://local_proxy@127.0.0.1:.../git/.insteadOf = https://github.com/, silently rerouting every GitHub URL through a per-repo-scoped proxy before my credentials are ever consulted. My access is overridden by infrastructure I didn't ask for and can't configure.
• There is no UI field to authorize additional repositories. The environment dialog exposes only name, network level, env vars, and setup script.
• The error is a naked 403 with zero indication of cause or remedy. It reads as "broken," not "restricted."

Impact: Multi-repo developers cannot use web sandboxes at all and are forced back to the terminal CLI. The security model didn't secure the multi-repo case — it deleted it, and then surfaced the deletion as an unexplained error. A control that makes the legitimate, common workflow impossible while giving the user no sanctioned way to enable it is a design failure, not a safety feature.

Requested changes:

1. First-class multi-repo support on cloud environments — an "additional repositories" configuration that adds repos to the git-proxy allowlist. Support N repos, not two; dozens is a normal number.
2. Honor the user's existing credentials (or provide an explicit, documented mechanism to authorize repos the connected account can already see) instead of silently overriding them with a session-scoped proxy token.
3. A real error message — name the unauthorized repo and link to the setting that grants access, instead of a bare 403.
4. Document the multi-repo story plainly, or state outright that web sessions are single-repo by design so people don't waste hours discovering it the hard way.