joshspicer

managed settings: forceRemoteSettingsRefresh fails closed (#332388) * policy: add managed-settings freshness contract Groundwork for making `forceRemoteSettingsRefresh` a real fail-closed startup gate (microsoft/vscode-internalbacklog#8825). Contract only — no behavior change, and nothing gates on freshness yet. Adds `managedSettingsFreshness.ts`, declaring the state machine shared by the fetch path, the policy gate and Policy Diagnostics so those consumers cannot drift: `NotRequired` / `Pending` / `Satisfied` / `Blocked`, the failure categories every inability-to-refresh maps to, and scoping by account + provider + endpoint so satisfaction is never transferable across accounts or GHE hosts. Replaces `shouldForceRemoteSettingsRefresh` with `resolveForceRemoteSettingsRefresh`, which resolves through `pickManagedSettings` instead of re-implementing precedence. Two fixes fall out: the file channel now participates (the old helper read only native MDM and server, silently ignoring managed-file delivery), and an explicit managed `false` is now distinguishable from an absent value, which a later change needs in order to know when the requirement may be cleared. The old helper had no production caller — it was left orphaned when 661f18fdeb7 reworked the managed-settings fetch — so this is inert. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * policy: enforce freshness invariants in the type Address PR feedback: `IManagedSettingsFreshness` was a bag of optional fields, so a consumer could construct `Blocked` with no failure, `Satisfied` with no scope, or attach `httpStatus`/`retryAfter` to states where they mean nothing — leaving the fetch, gate and diagnostics consumers free to drift despite the type. Models it as a discriminated union instead, so each active state requires the fields its contract defines. `Blocked` is itself a union keyed on the failure category, so a status code is required for an HTTP error, a backoff deadline for rate limiting, and neither is accepted elsewhere. `source` is now the shared `ManagedSettingsChannel` rather than `string`, and is required on the effective states, which also encodes that it is never `'none'` once a channel has supplied the control. Adds `@ts-expect-error` coverage for the three rejected shapes: the directives fail the build if any shape becomes constructible again. `isSameManagedSettingsFreshnessScope` is now a private helper with required arguments — the union guarantees a scope is present, so its undefined-tolerance was unreachable, and nothing outside this module used it. Also trims two over-long comments flagged in review. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: fail closed on forced managed settings refresh Require a fresh managed-settings response before enabling AI features when forceRemoteSettingsRefresh is effective. Preserve recovery through sign-in and retry, expose diagnostics, and cover native, server, file, failure, scope, and sign-out behavior. Related to microsoft/vscode-internalbacklog#8825. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: tighten managed settings recovery UX Re-render the Agents window when freshness failure details change and preserve startup notification deferral. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: address managed settings review feedback Scope cached server controls before precedence, avoid expired rate-limit poll loops, and align update-required recovery guidance across workbench and Agents window UI. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test: await explicit managed settings recovery refresh Classic web initialization intentionally skips the default-account fetch. Exercise the explicit refresh path before asserting the no-token fail-closed state so the browser suite observes the same lifecycle it is validating. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test: provide product name in policy overlay fixture Ensure managed-settings messages render Code - OSS instead of an undefined product label in component screenshots. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test: add managed settings failure modes Let the mock policy server return HTTP errors, malformed JSON, immediate disconnects, or no response until client timeout through presets, the GUI, and the control API. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: tighten forced managed settings recovery Improve forced-refresh progress and blocked-state UX, bound automatic retries after failures, preserve the ungoverned cache path, and simplify mock policy failure controls. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: close managed settings dialog on retry Start the explicit managed-settings refresh without making the dialog wait for the network request to complete. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: separate managed settings requirement copy Place the organization requirement and fetch failure remediation in separate paragraphs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: address managed settings review feedback Preserve cached and blocked freshness state, report failed manual syncs, retain pending mock-server edits, and include attempted scope in diagnostics. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: reduce managed settings freshness implementation Trim redundant contract commentary and tests, simplify refresh resolution, deduplicate failure transitions, and keep no-flag tests independent from retry bypass behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Force the Agent Host harness when the sandbox is managed (#331298) * Force the Agent Host harness when the sandbox is managed Enterprises in the sandbox pilot enforce `chat.agent.sandbox.enabled` (or `chat.agent.sandbox.enabledWindows`) through managed settings. Treat that as the governance signal for the chat harness: hide the legacy local harness from the new-chat pickers and default new chats to the Agent Host Copilot SDK, without the administrator having to also push `chat.editor.localAgent.enabled`, `chat.defaultToCopilotHarness` and `chat.editor.preferCopilotHarness`. A user- or workspace-level sandbox opt-in does not trigger this, and existing local chat sessions keep running on the local harness. The decision is reported in the Policy Diagnostics developer report. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Report the effective harness decision, not just the signal Address PR review feedback: - `chat.editor.localAgent.enabled` and `chat.defaultToCopilotHarness` descriptions claimed the policy always applies, but virtual workspaces are checked first and keep the local harness. Scope both descriptions to non-virtual workspaces. - Policy Diagnostics reported the harness as unconditionally hidden/forced whenever the policy signal was active. Split the section into the governance signal and the effective decision in this window, deriving the latter from the workspace kind and Agent Host enablement, which `getComputedDefaultSessionType` also depends on. Also export the harness setting ids from the platform module so the diagnostics labels stay in sync with the registration, and cover the case where a governed window has no Agent Host and no contributed harness. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Key enforcement on the only policy-backed sandbox setting A review council independently found that the `chat.agent.sandbox.enabledWindows` branch could never fire. `inspect().policyValue` is only populated for settings that declare a policy (`PolicyConfiguration.update`), and unlike `chat.agent.sandbox.enabled` that setting declares none, so its policy value is permanently undefined. The accompanying test fabricated a policy value the real configuration service cannot produce for that key, so it asserted behavior on a state unreachable in production. Key the governance signal on `chat.agent.sandbox.enabled` alone and drop the dead field, its picker listener, and the fabricated test case. Add a test locking in the real contract: the Windows setting must not act as a signal, so a local user opt-in on Windows cannot silently retire the local harness. Sandboxing is per-platform while enforcement is fleet-wide, so Policy Diagnostics now reports the platform-appropriate sandbox setting and whether the sandbox is actually active on this machine, instead of implying an enforced user is sandboxed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Key harness enforcement on the SDK sandbox managed setting The previous revision keyed on `chat.agent.sandbox.enabled` — the VS Code terminal-engine sandbox that the *local* harness uses — which is the wrong signal. The sandbox the pilot enforces is the Copilot SDK sandbox floor, delivered as the runtime-owned `sandbox.enabled` managed setting (`force-on-wins` in the runtime's managed-settings schema) and applied by the Agent Host over AHP. Read that key directly from the managed-settings channels instead of through a VS Code configuration policy: the control is runtime-owned, so mirroring it as a `policy:` declaration would invert ownership. `sandbox.enabled` is registered as a pipeline-consumed control (like `forceRemoteSettingsRefresh`) so native MDM watches it without any setting declaring it, and resolution follows the standard native MDM > server > file precedence. The enablement service exposes the result as a `managedSandboxEnforced` observable, which the harness decision points take as an explicit argument rather than re-reading configuration. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Apply the sandbox floor on every new-chat path and trim the diff A review council unanimously found that the floor never reached the real New Chat entry points. `managedSandboxEnforced` was an optional parameter defaulting to `false`, so every call site that was not updated silently opted out: the picker hid the local harness while the New Chat, panel and editor actions kept creating local sessions the user could no longer re-select, and a remembered local selection kept overriding the mandated default. Thread the flag through `getDefaultNewChatSessionResource` and remembered-type resolution, and supply it from every production call site. Cover both the resource path and the remembered-local override with a regression test. Also drop the file managed-settings channel: it was accepted as an optional constructor argument that no concrete service ever supplied, so its precedence branch was unreachable while diagnostics still reported the channel. Resolution is now native MDM plus server, matching `shouldForceRemoteSettingsRefresh`; wiring the file channel is follow-up work. Trim the rest to what the change needs: collapse the Policy Diagnostics section to a single table, unexport two module-private helpers, and revert the exported setting ids that only existed to label the removed diagnostics rows. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Resolve sandbox floor with managed-settings precedence Use the canonical native MDM, server, and file precedence when deciding whether the managed sandbox floor should retire the local harness. Observe file-managed changes and include that channel in policy diagnostics. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Encapsulate managed settings resolution Expose effective managed values from AccountPolicyService through a source-agnostic platform service. Agent Host now observes one resolved sandbox value instead of depending on native, server, and file channel implementations. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix Agent Host test service mocks Register the effective managed-settings service in web enablement tests and complete the Agent Host enablement mock used by chat component fixtures. Format the earlier test-stub updates so hygiene accepts them. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Restore chat harness setting descriptions Remove the managed-sandbox qualification from the existing harness setting descriptions and leave their behavior documentation unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Keep local harness when Agent Host is unavailable Apply the managed sandbox harness override only while Agent Host is enabled, including picker visibility and remembered session usability. Also reduce policy diagnostics to the effective harness decision. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Mock policy server: upstream passthrough, per-endpoint mocking, request log (#330711) * Mock policy server: upstream passthrough, per-endpoint mocking, request log The mock policy server only worked via product.overrides.json, which limits it to Code OSS running from sources, requires a reload after every change, and cannot exercise a stable/Insiders build or the CLI. Support a system HTTP proxy as a second wiring path, keeping product.overrides.json as the default. - Proxy anything not explicitly mocked to the real API (--upstream, default https://api.github.com) and stream it back, so a blanket proxy rule is safe: only endpoints deliberately switched on are faked. Rewrites Host, strips hop-by-hop headers and accept-encoding, forwards Authorization untouched, and reports upstream failures as 502. - Add a per-endpoint mock/passthrough toggle. Only managed settings is mocked by default; applying a preset implicitly switches mocking on. - Add managed-settings disk cache clearing. A cache entry under an hour old makes the runtime skip the network entirely, so an override is never even requested. Paths verified against managed_settings_cache.rs and path_helpers.rs, including the COPILOT_CACHE_HOME override. - Add a rolling request log (GET/DELETE /api/log) surfaced in the GUI, so it is obvious whether the client actually reached the server. - Add realistic managed-settings presets, each validated against the schema, and branch-point presets for the other endpoints. - Only warn about unknown schema keys on 2xx, and re-validate on status change: a 404/466/500 body is an error payload, not a policy document. - Route GUI assets from an explicit allowlist instead of probing public/ for anything that looks like a file, which would otherwise shadow proxied paths. UX: - Make save semantics consistent: everything auto-saves, with a pill showing whether the editor matches what is being served. - Surface mocked vs proxied via tab dots, a checkbox, and reactive help text. - Add a light palette; the dark-only one declared color-scheme: light dark, so UA form controls rendered light on a dark page. - Make the schema disclosure a real button with aria-expanded, add focus-visible styles, and expose tab state to screen readers. - Build the validation table from DOM nodes rather than innerHTML. - Surface save and wire failures instead of failing silently, and fall back to the shared endpoint definitions when the control API is unreachable. - Answer the GUI's own favicon request so it stops appearing in the log as a proxied 404. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Polish mock policy server workflows Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Route runtime policy diagnostics through proxy Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Minimize runtime proxy integration Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Move runtime proxy fix to separate PR Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address mock policy server review feedback Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Improve mock policy server troubleshooting (#333930) * Improve mock policy server troubleshooting Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix mock policy draft reconciliation Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

agentHost: bridge legacy settings to managed permissions (#330349) * agentHost: bridge legacy settings to managed permissions Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: apply managed settings with extension methods disabled Treat the typed managed-settings notification independently from generic extension requests, and cover the local host configuration. Initialize the Copilot managed-settings snapshot in the constructor to satisfy class-field ordering checks. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: isolate managed settings bridge plumbing Send managed permissions before fresh-connect restoration and assert that wire order. Inject the dedicated managed-settings service into the protocol handler so the provider-neutral agent service no longer exposes Copilot SDK types. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: keep managed permission types host-owned Use a restrictive host DTO across common and browser layers so Copilot SDK Node globals do not pollute Monaco compilation. Cover the exact local apply and clear notifications, and correct the AHP notification terminology. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: clean managed settings on handler disposal Remove every handler-owned client's managed permission contribution before disposing active connections or disconnect-grace timers, preventing stale restrictions when an endpoint handler is replaced. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: scope managed settings by protocol handler Namespace managed permission contributions per ProtocolServerHandler so handler-local client IDs cannot collide in the shared aggregate. Preserve same-handler reconnect identity and cover cross-handler cleanup. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Mock policy server: Add onboarding page (#331720) * Add mock policy server onboarding Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Clarify mock policy setup method selection Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Simplify mock policy runtime terminology Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Group mock policy setup status Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Emphasize mock policy connection status Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Move mock policy setup into modal Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Align mock policy proxy diagnostic Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

chat: Enforce per-marketplace plugin auto-updates (#327844) * chat: Enforce per-marketplace plugin auto-updates Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: Address plugin auto-update review feedback Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * policy: Regenerate marketplace policy data Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

accounts: avoid more redundant managed settings requests (#333823) * accounts: avoid redundant managed settings requests Preserve a fresh managed-settings cache during entitlement refreshes, deduplicate authentication sessions that match overlapping scope alternatives, and treat a managed-settings 404 as a final no-policy result. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * accounts: scope forced account refreshes Replace the managed-settings cache exception with explicit refresh targets. Chat entitlement updates now force only account entitlements, while policy sync and retry actions force only managed settings. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * accounts: simplify scoped refresh options Keep only the entitlement and managed-settings refresh modes used by production callers. Remove the general target enum, all mode, helper, and unused token and MCP refresh parameters. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * accounts: keep force refresh explicit Restore forceRefresh as a simple all-account-data boolean. Normal chat and managed-settings source updates now use ordinary cache-aware refreshes; only explicit policy sync and retry actions force all caches. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * accounts: preserve explicit entitlement refreshes Keep quota and upgrade checks fresh without forcing unrelated default-account caches. The all-or-nothing forceRefresh boolean remains reserved for explicit policy sync and retry actions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * accounts: test governed entitlement refresh Exercise the full account refresh path with a scoped, satisfied forceRemoteSettingsRefresh cache. Verify entitlement refresh requests only entitlement data and preserves satisfied managed-settings freshness before full force refresh. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * accounts: trim managed settings regression diff Restore unrelated test wording and retry documentation, inline the managed-settings force check, and narrow the governed entitlement regression to the behavior under review. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Polish mock policy server UI (#334122) * Polish mock policy server UI Improve schema controls, delivery setup, theming, and the editable schema source workflow. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address mock policy server review feedback Restrict schema source mutation to loopback URLs, avoid :has state styling, and keep the schema status live region rendered. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

agentHost: managed permission fixes for shell paths and read prompts (#333249) * agentHost: let managed permissions see shell paths, and stop misstating why a read is gated Two independent fixes to Copilot managed-permission handling in the agent host. **Enable the runtime's shell-script safety classifier.** Managed permission rules such as `Read(...)` and `Edit(...)` match on filesystem paths. For a shell command the runtime only populates `possiblePaths` and `hasWriteFileRedirection` when the session option `enableScriptSafety` is set; otherwise `assess_safety` short-circuits and returns a degenerate assessment with no paths, no redirection flag, and the whole script as a single non-read-only command. The agent host never set the option, so every shell command reached the permission layer carrying no paths at all. Observed effect: with a managed `deny: Edit(/.github/workflows/**)` in force, `echo x >> .github/workflows/f.yml` surfaced as an ordinary shell prompt and modified the file. Even `tail -3 f` was reported as non-read-only. The Copilot CLI opts in at session creation; the agent host did not. The SDK exposes the option on `SessionUpdateOptionsParams` rather than on `SessionConfig`/`ResumeSessionConfig`, so it is applied from `_finalizeSession` via `rpc.options.update`. That is the single point shared by the create, resume, and resume-fallback paths, and it runs before the wrapper is handed to a caller, so no turn can start without it. Failure is logged at error rather than thrown, matching the surrounding post-launch option updates. This restores the path data the permission layer needs. Note that matching managed path rules against a shell command's `possiblePaths` is a separate runtime-side concern and is not addressed here. **Report the actual reason a read needs approval.** `getPermissionDisplay` returned "Allow reading file outside of workspace?" for every `read` request, but a read is gated for several reasons: the path is outside the workspace, a managed or scoped rule matched it, managed rules are active and an unmatched request defaults to ask, or the model asked to escape the sandbox. Reads inside the workspace were therefore told they were outside it. The branch also ignored `requestSandboxBypass`, which was already being computed for reads, while the neighbouring `shell` and `write` branches vary their titles. The title is now chosen from the request: a sandbox-bypass read mirrors the shell wording, a genuinely outside path keeps the original title, and anything else uses a neutral "Allow reading file?". Containment uses `extUriBiasedIgnorePathCase.isEqualOrParent` so platform case-insensitivity is respected, and a relative path, unknown path, or unknown working directory falls back to the neutral title rather than asserting a location the request does not establish. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: address review — multi-root read titles and fail-closed script safety Two review findings on the previous commit. **Account for every workspace root before claiming a read is outside it.** The read confirmation title compared the path only against the primary process root, so in a multi-root session a read under a peer root (`ICopilotSessionLaunchBase.additionalDirectories`) still reported "outside of workspace" — the same misleading diagnosis this change set exists to remove. `getPermissionDisplay` now takes the session's additional directories and treats a path as outside only when no root contains it. **Fail closed when script safety cannot be enabled under managed rules.** Logging and continuing left the session usable after the runtime failed or refused to enable the classifier, which silently degrades enterprise enforcement: managed `Read(...)`/`Edit(...)` rules cannot inspect shell redirect targets, permitting exactly the bypass this change targets. Launch now fails and the orphaned session is disconnected when managed permission rules are in force. Without managed rules there is no policy to escape, so a transient or compatibility failure is logged as a warning and the session continues rather than making every user's sessions unlaunchable. `_finalizeSession` disconnects `raw` before rethrowing, since nothing owns that session until it is wrapped. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: keep the out-of-workspace read title reachable The unauthorized-path gate is the case the original hardcoded title described, and narrowing the title by path containment alone made it unreachable. That gate runs ahead of the per-kind gates and fires only for paths outside the allowed directories. It is not a distinct request kind: it reuses the access kind, so it arrives as `kind: "read"`, but it carries `paths` (plural) rather than the per-kind `path`. `getPermissionDisplay` reads `request.path`, which is therefore undefined for these requests, so the containment check could not succeed and every out-of-workspace read fell through to the neutral title — losing the one diagnosis that was correct before this change set. A request carrying `paths` is treated as out-of-workspace by construction, which is a stronger signal than comparing against the workspace roots: it is the runtime's own verdict that the path is outside the allowed directories, and it covers directories the user approved earlier that are not workspace roots. The SDK's `PermissionRequestRead` does not model `paths`, hence the structural check rather than a typed discriminator. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: make the script-safety launcher tests exercise the success path `Array.push` returns a number, so a mocked `options.update` that returned it gave `_applyScriptSafety` a `result.success` of `undefined`. Every launcher test therefore took the SDK-rejection branch and passed without ever exercising a successful enablement. The mocks now return the SDK-shaped `{ success: true }` after recording the options, and the enablement test runs with managed rules in force so anything short of a successful enablement fails the launch instead of warning. Verified by flipping the mock to `{ success: false }`, which fails that test. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: fix the SDK-sandbox smoke test for script-safety classification Enabling the runtime's script-safety classifier changed which commands reach the host's permission layer. `commands_requiring_approval` skips commands the classifier reports as read-only, so the scenario's `echo` is now resolved by the runtime without ever raising a permission request. The host's "Auto-approving sandboxed shell command" branch therefore never runs, and the SDK-sandbox smoke test failed waiting for that log entry on Linux and macOS. (Windows skips both sandbox tests, which is why it stayed green.) Before this PR the classifier short-circuited and reported the whole script as a single non-read-only command, which forced the prompt the test was keyed to. The prompt was redundant: the command still runs mxc-wrapped under the pushed sandbox policy, so not asking is the better behavior, and the assertion is simply stale rather than the code being wrong. The test now keys on `Tool started: bash`, which proves the SDK's own shell tool ran the command, and keeps the `Applied SDK sandboxConfig` and negative `[ShellManager]` assertions. Polling on the tool run is also a stricter gate for the negative assertion than the old pre-execution entry, since a competing ShellManager run would have been logged by that point. The host auto-approve branch still governs non-read-only sandboxed commands and remains asserted by the custom-terminal-tool test above. Verified by replaying all three assertions against the agenthost.log artifact from the failing macOS run: both matches hold and the ShellManager pattern is absent. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: fail closed on script safety for every session `IAgentHostManagedSettingsService` only carries the legacy VS Code settings bridge — its own documentation says so, and that new enterprise controls belong directly in the SDK's managed-settings contract. Server and MDM policy is discovered by the runtime itself under `enableManagedSettings`, so it never appears in `permissions`. Gating fail-closed on that signal therefore inverted the intent: a session governed solely by GitHub or MDM policy looks unmanaged from the host's side, so an `options.update` failure left exactly the policy-bearing sessions running without the classifier that managed `Read(...)`/`Edit(...)` rules depend on to see shell paths. Querying the runtime's effective managed-settings result instead would cost a proxy resolution and a separate SDK import on every launch, and would make a security control depend on a second fallible lookup. The option is cheap, present in the pinned SDK, and accepted by the runtime, so it is now treated as required for every session and a failure fails the launch. The launcher tests cover both a client-bridged session and one where the host sees no managed rules at all, since that is what an enterprise session governed only by server or MDM policy looks like from here. The shared resume-fallback mock gained the `rpc.options.update` surface a real session always has; without it the fixture failed on a missing `rpc` rather than on the behavior under test. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * agentHost: cover the rejected-RPC path of the script-safety fail-closed guard `session.options.update` reports `success: true` for any patch the runtime accepts and signals real problems by failing the request, so a rejected RPC — not a `success: false` body — is the path a genuine enablement failure takes. Both existing fail-closed tests drove the `success: false` branch, leaving the `catch` that logs the reason and aborts the launch uncovered. Adds a test that rejects the update and asserts the launch fails closed, the original error propagates, and the orphaned session is disconnected. Also drops the managed rules from the success test. They no longer gate the behavior, so passing a `deny` rule implied a dependency that is exactly the one the fail-closed change removed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Dmitriy Vasyura <dmitriv@microsoft.com>