Radius.Core/environments incorrectly restricts a Kubernetes namespace to a single environment #12420

Steps to reproduce

1. Confirm there is a single resource group with a Radius.Core/environments using the default Kubernetes namespace:

   ❯ rad group list
   GROUP     ID
   default   /planes/radius/local/resourcegroups/default
   
   ❯ rad env list --preview
   RESOURCE  TYPE                      GROUP     STATE
   default   Radius.Core/environments  default   Succeeded
   
   ❯ rad env show default --preview
   RESOURCE  TYPE                      GROUP     STATE
   default   Radius.Core/environments  default   Succeeded
   
   PROVIDER    PROPERTIES
   kubernetes  namespace: 'default'
   

2. Attempt to create a second environment in the same resource group without specifying a namespace:

   ❯ rad env create test --preview
   Error: {
     "code": "Conflict",
     "message": "Environment /planes/radius/local/resourcegroups/default/providers/Radius.Core/environments/default with the same namespace (default) already exists"
   }
   

3. Create a new resource group and create an environment in it without specifying a namespace:

   ❯ rad group create test
   System.Resources/resourceGroups/test created
   
   ❯ rad env create test --preview -g test
   Radius.Core/environments/test created
   

4. Observe that the new environment was created successfully, despite sharing the default Kubernetes namespace with the first environment.

Observed behavior

The one-environment-per-Kubernetes-namespace constraint is enforced within a single resource group, but not across resource groups. Creating a second resource group and creating an environment in it without specifying --kubernetes-namespace silently succeeds and defaults to the default namespace — the same namespace already occupied by the first environment.

This makes the constraint trivially bypassable: the same operation that is blocked in one resource group is silently permitted in another, with no warning that the namespace is already in use.

Desired behavior

A deliberate, documented policy decision should be made and consistently enforced. The recommended approach is:

Option A (recommended) — Remove the restriction: Allow multiple environments per namespace, but require that recipes generate unique resource names (e.g., scoped by application or environment name) to avoid collisions. This accommodates teams that run multiple applications in a single namespace and aligns with common Kubernetes practices. Apply this policy uniformly — the current namespace uniqueness check should be removed entirely.

Option B (alternative) — Enforce the restriction globally: No two environments may share a Kubernetes namespace, regardless of which resource group they belong to. The namespace uniqueness check must be cluster-wide, not resource-group-scoped.

Either way, the current behavior — where the constraint is enforced within a resource group but silently bypassed across resource groups — is incorrect and must be fixed.

Workaround

Explicitly specify a unique Kubernetes namespace when creating each environment: rad env create <name> --preview -g <group> --kubernetes-namespace <unique-namespace>

rad Version

CLI Version Information:
RELEASE VERSION BICEP COMMIT
0.59.0 v0.59.0 0.42.1 2bf2c25

Operating system

No response

Additional context

No response