[FEATURE] Per-repository default cloud environment for Claude Code on the web

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a Claude Code session starts on the web — whether from claude.ai/code, --remote, the mobile app, or the Slack bot — there is no way to bind a specific cloud environment to a specific repository. The session uses whatever environment the user has currently selected, which is workable for accounts with a single environment but breaks down quickly when an account has multiple environments and multiple repos.

The Slack-triggered case is where this hurts most. When @Claude is mentioned in a thread and routed to Claude Code on the web, the bot auto-selects the repository from conversation context, but there is no surface for the user to indicate which environment that repo should run in, and no visibility into which environment was chosen.

Proposed Solution

Allow a default cloud environment to be associated with a repository, declared in the repo's .claude/settings.json so it is version-controlled and shared across the team:

{
  "cloudEnvironment": {
    "default": "backend-services"
  }
}

The environment name would be matched against environments configured on the user's claude.ai/code account. Resolution order when a session starts for the repo (Slack, --remote, web, mobile):

If .claude/settings.json declares a default that exists in the user's environments → use it.
If declared but no environment of that name exists for the user → fall back to the user's account default, and surface a message indicating the configured environment was unavailable.
If not declared → current behavior (user's account default).

Additionally:

Surface the chosen environment when the session starts ("Starting session for org/repo in backend-services environment") so the user knows what they got. This is especially valuable in Slack, where the user isn't looking at the environment selector.
Allow override at session start — e.g., a Slack action button to pick a different environment, or a flag for --remote.

Alternative Solutions

1. Account-level per-repo mapping in claude.ai/code settings

Rather than .claude/settings.json, surface a UI at claude.ai/code that lets each user map repos to environments (a table of repo → environment). Pros: no schema change, no commit required, works for repos the user can't push to. Cons: per-user drift across a team, no version control, doesn't travel with the repo.

1. Environment-level repo allowlist (inverse mapping)

Instead of repos pointing at environments, each environment declares which repos it applies to. When a session starts for a repo, the system finds the environment whose allowlist contains it. Pros: fits the existing "manage environments" UI naturally. Cons: ambiguous when multiple environments claim the same repo; less intuitive than repo → env.

1. Branch-aware environment selection

Extend whatever solution lands so the binding can vary by branch pattern (e.g., main → production-like, feature/* → dev). Pros: useful for repos where different branches need different toolchains or secrets. Cons: probably overkill for v1; better as a follow-up.

1. Interactive picker at session start

Rather than a default, prompt the user to choose an environment every time a session starts. In Slack, this would be a dropdown in the bot's first message; in the web UI, a modal. Pros: zero config, full visibility. Cons: friction on every task, defeats the async value of the Slack flow ("fire and forget"), bad UX for routine work.

1. Naming convention auto-match

If an environment's name matches the repo name (or a prefix of it), auto-select it. Pros: zero config for users who follow the convention. Cons: magic behavior, breaks silently when names drift, doesn't help users who name environments by purpose ("debugging", "infra") rather than by repo.

1. Slack-specific configuration

Add a /claude-env <name> slash command, or a per-channel default set by workspace admins. Pros: fixes the Slack case directly. Cons: doesn't solve --remote, mobile, or web — just Slack.

1. Status quo + better visibility

Don't add configuration at all; just surface clearly which environment was chosen at session start, and make it one click to switch and restart. Pros: cheapest implementation, low risk. Cons: doesn't fix the underlying problem of needing to remember/manually select per repo, just makes the failure mode more legible.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

Teams with multiple repos, or a monorepo containing multiple services, where different services or workflows benefit from different cloud environments. Concrete scenarios:

A repo whose services need distinct environment variables or setup scripts, where the "right" environment depends on which part of the codebase a task touches.
Infrastructure work that requires specific CLIs (e.g. gcloud, aws, kubectl) pre-installed via setup script in a dedicated environment, vs. application work that runs in a slimmer environment.
Shared Slack channels where any engineer on the team can @Claude a coding task. Without per-repo binding, every engineer has to remember to manually select the correct environment in the web UI before the task runs — which isn't possible at all when the trigger is a Slack mention.

Additional Context

Why version-controlled (.claude/settings.json) rather than per-user account setting

Works for every engineer on the team without per-user configuration drift.
Travels with the repo. If a fork or branch needs a different environment, that's a normal PR.
Consistent with the existing pattern for hooks, MCP servers, skills, agents, and commands — all of which are repo-scoped via .claude/.

Related issues

#24379 — binding a default cloud environment per repository (closed as stale)
#30200 — environment selection and visibility when starting Claude Code from Slack (closed as stale)
#46386 — docs update noting remote sessions now auto-create a default environment (open, adjacent but distinct)