Problem

Org admins have no way to centrally push configuration — especially environment variables — to developers' local Copilot CLI installs. Today the only org-managed env mechanism is Agents/Codespaces secrets, which only reach GitHub-hosted cloud environments. For the local CLI (incl. VS Code dev containers on Colima/Lima/Podman), the only options are MDM-placed files or per-host provisioning — neither of which reaches into an unmanaged container.

Request

A server-delivered, org/enterprise-managed settings layer for the local Copilot CLI — fetched at auth and refreshed periodically, taking precedence over user/repo settings — that can set a managed env block, e.g.:

// org-managed settings (delivered over the network, not a local file)
{ "env": { "MY_ORG_CONFIG_VALUE": "…" } }

These vars would apply to CLI sessions (and ideally subprocesses/plugin hooks), so org-distributed plugins/tools can pick up required config with no MDM and no per-machine provisioning.

Why existing mechanisms don't cover it

• Agents/Codespaces secrets → cloud agent / Codespaces only; never reach the local CLI.
• Org/enterprise policies (Feature Request: Granular organizational policies for Copilot CLI tools (e.g., bash, file access) #1971) → governance (enable/disable, model & MCP allowlists), not arbitrary config/secret delivery.
• .env loading (Feature: Support .env file loading and per-agent environment variable scoping #2879) → local files the developer manages, not org-pushed.

Prior art

Claude Code ships exactly this as server-managed settings (admin console → delivered at auth, refreshed hourly, reaches inside containers, supports an env block) — see code.claude.com/docs server-managed-settings. Enterprise-managed models already landed for Copilot CLI (#3730), so an enterprise-managed settings/env layer is a natural extension. Would also complement the Claude-parity work in #2471.