Empty service `env: {}` is dropped on save, so an explicit empty environment scope cannot be expressed

[huimiu]

Problem

azure.yaml cannot express "this service declares an empty environment scope." An explicitly empty env: {} is silently dropped when the project is saved, so it is indistinguishable from a service that never declared env: at all.

Root cause

project.SaveConfig re-parses the raw config map into a typed ProjectConfig and re-marshals that typed value:

// cli/azd/pkg/project/project.go:272
func SaveConfig(ctx context.Context, config config.Config, projectFilePath string) error {
	projectBytes, err := yaml.Marshal(config.Raw())
	...
	projectConfig, err := Parse(ctx, string(projectBytes))
	...
	return Save(ctx, projectConfig, projectFilePath)
}

ServiceConfig.Environment is a plain map with omitempty:

// cli/azd/pkg/project/service_config.go:68
Environment osutil.ExpandableMap `yaml:"env,omitempty"`

osutil.ExpandableMap is map[string]ExpandableString with no custom MarshalYAML, so omitempty drops a zero-length map along with a nil one.

Reproduction

Against the real LoadConfig / SaveConfig:

Input	Written azure.yaml	Raw Get("services.myagent.env")
cfg.Set("services.myagent.env", map[string]any{})	no env: key at all	found = false
cfg.Set("services.myagent.env", map[string]any{"FOO": "${BAR}"})	env: with the value	found = true

Why it matters

Extensions decide environment scoping by probing whether env: is present. In the Foundry extensions, serviceEnvDeclared reads GetServiceConfigValue(Path: "env") and feeds ServiceRunContext.HasServiceEnvironment. When that is false, the run and deploy paths fall back to forwarding the entire azd environment into the child process.

Because an explicit empty scope cannot survive a save, any generated service with no variables of its own reads as legacy and inherits everything, while a service that happens to declare one variable is fully isolated. Scoping ends up determined by an incidental template detail rather than by intent.

This blocked the empty-scope work in #9079: the call sites were changed to always write the section, then reverted in 88a6b76be because the write never reached the file. The tests there passed only because the recording stub captured the RPC in memory and never round-tripped through SaveConfig.

Possible directions

1. Change ServiceConfig.Environment to *osutil.ExpandableMap. With a pointer, omitempty drops only nil, so absent stays absent and explicitly empty round-trips. There are roughly nine field usages across pkg/project, internal/cmd, and the agents extension.
2. Give ServiceConfig custom marshalling that tracks whether env: was present in the source document.
3. Drop omitempty. Smallest change, but every service that never declared env: starts emitting env: {} on save, which is a visible and unwanted diff for existing projects.

Option 1 looks like the smallest change that preserves both behaviors exactly.

Acceptance

• A raw config Set of an empty env section survives SaveConfig and is visible to a follow-up raw Get.
• A service that never declared env: still saves without an env: key.
• A test in pkg/project asserts against the written azure.yaml rather than a stub, since that is the layer that decides this.
• Foundry extension call sites can then declare an explicit empty scope again.

[huimiu]

Related defect in the same API surface: service names containing .

Surfaced by Copilot review on #9079 (r3703294338, r3703294383, r3703294414, r3703294459, r3703294483). Filing it here because it is the same ProjectService config API and would likely be fixed in the same pass.

Problem

The service-config RPCs build a dot-notation path by interpolating the service name, and config.Config splits that path on .:

// cli/azd/internal/grpcserver/project_service.go:623
servicePath := fmt.Sprintf("services.%s.%s", req.ServiceName, req.Path)

// cli/azd/pkg/config/config.go:215
parts := strings.Split(path, ".")

For a service named research.tools, Path: "env" becomes services.research.tools.env, which walks services → research → tools → env instead of addressing the literal services["research.tools"] map key.

validateServiceExists does not catch this, because it looks the name up as a literal map key:

// cli/azd/internal/grpcserver/project_service.go:112
if projectConfig.Services == nil || projectConfig.Services[serviceName] == nil {

So the request passes validation and then reads or writes the wrong node.

Affected RPCs

All four service-config methods in project_service.go interpolate the name the same way:

Line	Method
556	GetServiceConfig
623	GetServiceConfigValue
684	SetServiceConfigSection
821	UnsetServiceConfigValue

Reads return Found=false for a service that does have the value. Writes are worse: cfg.Set("services.my.agent.env", ...) creates a nested services.my.agent node, so SaveConfig re-parses it as a service named my carrying an agent key in AdditionalProperties, corrupting azure.yaml.

Why it matters for extensions

Extensions cannot work around this. The path is assembled server-side and the client only supplies ServiceName, so there is no escaping or quoting available to them. Any fix has to happen in the core API.

The impact is also silent rather than loud. Foundry service targets decide environment isolation by probing whether env: is present, so a false Found=false reads as "legacy service" and the full project environment is forwarded into the child process instead of the declared scope.

Reachability

Narrow today, but not impossible:

• azdext.ValidateServiceName accepts . (^[a-zA-Z0-9][a-zA-Z0-9._-]{0,62}$). That regex is an input-safety filter, not a statement of support.
• schemas/v1.0/azure.yaml.json puts no pattern constraint on service keys, so a hand-written services: { "research.tools": ... } parses fine.
• No first-party generator produces a dotted name. The agents extension routes names through agent_yaml.ValidateAgentName, which allows only alphanumerics and internal hyphens.

So it requires a hand-authored azure.yaml, but nothing rejects one.

Possible directions

1. Give the RPCs a structured lookup that treats ServiceName as a literal map key and only applies dot-splitting to Path.
2. Add path-segment escaping to config.Config and escape the service name before interpolation.
3. If dotted service names are not intended to be supported, reject them at load time and tighten ValidateServiceName, so the failure is explicit instead of silent.

Note on existing exposure

This is not new to #9079. main already calls GetServiceConfigValue(ServiceName: svc.Name, Path: "uses") at cli/azd/extensions/azure.ai.agents/internal/cmd/optimize_apply.go:207 with the same exposure. #9079 adds more consumers of the same API, which is why it came up there.