Reconstruct batch 113/124: 2026-10-18 → 2026-10-20 (agenthost, chat, mcp, sessions)

.github/skills/policy-and-managed-settings/github-managed-settings.md

@@ -152,7 +152,7 @@ managedSettings: { [COPILOT_ENABLED_PLUGINS_KEY]: { type: 'string' } },
 
 `IPolicyData.managedSettingsActive` is `true` when a channel contributes managed-settings governance. `AccountPolicyService.getPolicyData` derives it from effective managed settings and raw settings that normalization cannot represent, independently of which keys VS Code declares. Presence governs for existing settings. The `vscode.temporaryAllowLocalHarness` control is excluded from this flag at every value; its explicit false value separately disables Local, Claude, and Codex without affecting unrelated presence-gated features. Channel resolution retains its value for precedence and diagnostics, but neither its normalized value nor its raw container contributes general governance. Empty server responses or responses containing only this control explicitly clear a previously cached raw-governance flag.
 
-The `Claude3PIntegration` and `Codex3PIntegration` policies both use `thirdPartyAgentEnabledValue`, which forces its setting to `false` when the account disables chat preview features, when `managedSettingsActive` is `true`, or when effective `vscode.temporaryAllowLocalHarness` is boolean `false`. Rationale: managed settings are composed and enforced by the Copilot runtime and never reach the Claude or Codex harnesses, so leaving those harnesses available would hand a governed user an ungoverned path around every control the enterprise set. Local eligibility is separate: managed `permissions.*` and `sandbox.*` do not change its harness-selection logic, while `vscode.temporaryAllowLocalHarness: false` explicitly prohibits Local.
+The `Claude3PIntegration` and `Codex3PIntegration` policies both use `thirdPartyAgentEnabledValue`, which forces its setting to `false` when the account disables chat preview features, when `managedSettingsActive` is `true`, or when effective `vscode.temporaryAllowLocalHarness` is boolean `false`. Rationale: managed settings are composed and enforced by the Copilot runtime and never reach the Claude or Codex harnesses, so leaving those harnesses available would hand a governed user an ungoverned path around every control the enterprise set. This mirrors the runtime-owned `sandbox.enabled` floor retiring the local harness (`IAgentHostEnablementService.managedSandboxEnforced`).
 
 Invariants:
 

.github/skills/policy-and-managed-settings/policy-support-maintenance.md

@@ -44,7 +44,7 @@ Preserve these boundaries:
 - Readiness is report-only. Applied gaps never change rollout, harness selection, or Local picker visibility. There is no compatibility holdback or acceptance setting/policy. Accepting a gap for rollout must not relabel it as enforced.
 - Existing experiments, preferences, remembered/inherited and explicit choices retain their behavior. No storage mutation, conversation migration, Chat banners, message blocking, or additional telemetry.
 - `ChatEditorPreferCopilotHarness` is a preference, not a hard Local/Copilot lock. False does not prohibit explicit or remembered Copilot choices. Hard mandates require an explicit enforcement contract outside this diagnostic feature.
-- Existing enterprise-required sandbox enforcement in Copilot and managed-settings freshness behavior remains authoritative. Local cannot satisfy the runtime sandbox floor, but `permissions.*` and `sandbox.*` do not affect harness selection or Local eligibility.
+- Existing enterprise-required sandbox and managed-settings freshness behavior remains authoritative. Local cannot satisfy the runtime sandbox floor.
 - A readiness report with no known gaps is not an attestation of runtime parity. State what the detector does not inspect.
 
 Update the inventory, predicates, descriptions, readiness report, and tests as one coherent change. Keep UI descriptions focused on concrete admin/user consequences rather than copying a raw status label.
@@ -59,7 +59,7 @@ The readiness summary reports policy names, configuration keys, source labels, a
 
 - Test absent, permissive, restrictive, partial, and removed policy values.
 - Test Local and Copilot rollout defaults with and without applied gaps. Diagnostics must neither veto Agent Host selection nor promote a Local baseline.
-- Cover remembered and inherited automatic choices without storage mutation, explicit choices, other providers, virtual workspaces, host unavailability, hidden-Local picker behavior, and independence from runtime sandbox settings.
+- Cover remembered and inherited automatic choices without storage mutation, explicit choices, other providers, virtual workspaces, host unavailability, hidden-Local picker behavior, and sandbox precedence.
 - Test existing harness policy-over-user precedence using real configuration layering, and test policy removal and inventory graduation to enforced.
 - Test readiness content, including uncertainty and safe rendering. Do not include raw sensitive values in new diagnostics summaries.
 - For bridge changes, exercise the bundled runtime with isolated temporary homes and a synthetic local model. Check create, cold resume, removal, managed asks under Allow All/assisted modes, and unaffected requests. No real Copilot sign-in or device-policy changes should be needed for these fixtures.

.github/skills/policy-and-managed-settings/sdk-runtime-policy.md

@@ -34,21 +34,23 @@ Do not add a VS Code `policy:` merely to mirror runtime policy. Do not add a Git
 
 ### Harness eligibility for managed policy
 
-Managed `permissions.*` and `sandbox.*` settings do not select a harness, hide Local, block Local requests, or migrate Local history. Harness selection follows the existing rollout settings, preferences, remembered and explicit choices, and availability logic. Only `vscode.temporaryAllowLocalHarness: false` explicitly prohibits Local. VS Code preserves permission-key presence across server and file delivery and watches the runtime's declared permission keys in native MDM; it does not parse or enforce rule grammar. Local does not enforce runtime-only sandbox and permission settings. Permissions do not turn sandboxing on.
+A non-empty effective managed `permissions.deny` list, or managed `sandbox.enabled: true`, requires Copilot Agent Host, subject to the existing temporary Local escape hatch. A valid empty deny array, other `permissions.*` settings, and other sandbox settings do not independently require Agent Host. Malformed deny values remain fail-closed for runtime validation. VS Code only checks whether the deny list is empty; it does not interpret or enforce rule grammar. Native MDM continues watching the runtime's declared permission keys. Permissions do not turn sandboxing on. Explicit `vscode.temporaryAllowLocalHarness: false` still overrides the escape hatch. Claude/Codex retain their separate presence-based managed-settings governance.
+
+When effective enterprise policy prohibits Local, the harness picker keeps its row visible but disabled, with a policy explanation and a link to learn why Local is disabled. This presentation does not make Local selectable, usable as a fallback, or exempt from request blocking and migration. Personal visibility settings still apply when no enterprise restriction is active.
 
 The legacy network boundary bridge targets runtime-native Domain operations only. It does not change tool selection, the experimental terminal override, or VS Code client fetch. Native `limitTo` enforcement in the integrated browser is deferred; existing browser controls remain unchanged. Browser/client tools, experimental terminal overrides, arbitrary extension/MCP networking, and client-run code must not be assumed to inherit the runtime's Domain enforcement.
 
-Resolve initial account policy before choosing or activating Local. When Local is explicitly prohibited, new chats select Copilot Agent Host, including explicit or remembered Local choices. An unavailable host must produce an actionable error, never a Local fallback. Displaying an existing non-archived Local chat automatically moves its transcript and unsent draft/attachments to Copilot, without sending or copying model and permission settings. Background history loads do not migrate chats. The original is archived only after the destination opens, and archived originals remain readable without migrating again. On failure, the original remains read-only with a Move to Copilot retry action; sending, retrying requests, and queueing stay blocked. The destination uses its normal policy-constrained defaults. Removing the explicit prohibition restores normal Local eligibility without rewriting preferences. Editor inline chat's limited read/edit flow remains available as an explicit exception; this gate does not enforce runtime permission rules on those edits.
+Resolve initial account policy before choosing or activating Local. When effective policy requires Agent Host, new chats select Copilot, including explicit or remembered Local choices. An unavailable host must produce an actionable error, never a Local fallback. Displaying an existing non-archived Local chat automatically moves its transcript and unsent draft/attachments to Copilot, without sending or copying model and permission settings. Background history loads do not migrate chats. The original is archived only after the destination opens, and archived originals remain readable without migrating again. On failure, the original remains read-only with a Move to Copilot retry action; sending, retrying requests, and queueing stay blocked. The destination uses its normal policy-constrained defaults. Removing the requirement restores normal Local eligibility without rewriting preferences. Removing `permissions.deny` or replacing it with a valid empty array removes its harness requirement. Legacy `ChatToolsAutoApprove` alone and personal sandbox preferences do not require Agent Host. The same request gate applies to old Local chats under a managed sandbox floor; virtual workspaces and unavailable hosts cannot silently run Local instead. Editor inline chat's limited read/edit flow remains available as an explicit exception; this gate does not enforce runtime permission rules on those edits.
 
 ## Host-Injection Lifecycle
 
 ### Approval modes
 
-Copilot Agent Host resolves native mode restrictions before applying the legacy global approval fallback. An explicitly configured new mode restriction replaces the legacy blanket restriction; `defaultMode` alone does not. Other bridged restrictions, including the per-tool bypass lock and terminal asks, remain in force. The host publishes selectable modes and the starting selection in session config, validates client writes, and reconciles runtime refusals to the actual applied mode. Desktop and remote Copilot Agent Hosts use the same policy path. Native settings resolve where the host runs; this does not replicate desktop device policies to remote hosts. The UI must not reapply the legacy clamp to host-reported choices. Local offers Default, Allow All, and Autopilot, not Assisted. Managed permissions do not change Local harness eligibility or implement runtime modes in Local; its existing controls remain in effect. Clients retain the legacy guard until a host advertises its approval-policy report. Both standard `approvalMode` and VS Code `autoApprove` reports follow this contract. The report requires a valid approval binding. Under the legacy restriction, discover that binding before creation even without an explicit preference, and seed Manual when the host does not publish its own policy report. Host-owned approval reports are never forwarded as client configuration inputs. Explicit and remembered approval preferences are normalized after schema discovery, before prewarming a backend; they must not be irreversibly clamped before discovery. Defaults are only startup preferences; no additional durable pre-override restoration state is maintained. Restart to apply changed managed settings. A client restart refreshes selectable modes for already-loaded chats even while their SDK sessions remain disconnected, without resuming them or sending a prompt. The last runtime-reported applied mode is not overwritten by this preview.
+Copilot Agent Host resolves native mode restrictions before applying the legacy global approval fallback. An explicitly configured new mode restriction replaces the legacy blanket restriction; `defaultMode` alone does not. Other bridged restrictions, including the per-tool bypass lock and terminal asks, remain in force. The host publishes selectable modes and the starting selection in session config, validates client writes, and reconciles runtime refusals to the actual applied mode. Desktop and remote Copilot Agent Hosts use the same policy path. Native settings resolve where the host runs; this does not replicate desktop device policies to remote hosts. The UI must not reapply the legacy clamp to host-reported choices. Local offers Default, Allow All, and Autopilot, not Assisted. Mode restrictions alone do not disable the Local harness or implement runtime modes in Local; its existing controls remain in effect. Clients retain the legacy guard until a host advertises its approval-policy report. Both standard `approvalMode` and VS Code `autoApprove` reports follow this contract. The report requires a valid approval binding. Under the legacy restriction, discover that binding before creation even without an explicit preference, and seed Manual when the host does not publish its own policy report. Host-owned approval reports are never forwarded as client configuration inputs. Explicit and remembered approval preferences are normalized after schema discovery, before prewarming a backend; they must not be irreversibly clamped before discovery. Defaults are only startup preferences; no additional durable pre-override restoration state is maintained. Restart to apply changed managed settings. A client restart refreshes selectable modes for already-loaded chats even while their SDK sessions remain disconnected, without resuming them or sending a prompt. The last runtime-reported applied mode is not overwritten by this preview.
 
 **Simple rule:** an explicitly configured valid new mode restriction replaces the legacy blanket mode policy on the supported Copilot Agent Host; otherwise the old policy is the fallback. `defaultMode` alone never removes restrictions.
 
-**Potential surprise:** scenarios 6 and 8 below allow Allow All despite the old key being false. Setting a new mode restriction opts into the new group, so an unspecified mode is not implicitly restricted by the legacy key. Other managed/per-tool restrictions still apply. These rows assume all modes are supported and show selectable modes, not defaults. Local availability remains subject to normal harness selection and an explicit Local prohibition; runtime-only controls are not enforced by Local. The legacy JSON is logical policy notation, not an OS-specific deployment format.
+**Potential surprise:** scenarios 6 and 8 below allow Allow All despite the old key being false. Setting a new mode restriction opts into the new group, so an unspecified mode is not implicitly restricted by the legacy key. These mode settings alone do not disable Local; its eligibility follows the harness rules above. Other managed/per-tool restrictions still apply. These rows assume all modes are supported and show selectable modes, not defaults. The legacy JSON is logical policy notation, not an OS-specific deployment format.
 
 ✅ Allowed; ❌ Blocked.