Inject and validate the two learning-mode capabilities

[richiemsft]

Recognize learningModeLogging (deny-and-record) and permissiveLearningMode (audit / allow-all) as distinct, reserved internal capabilities for the AppContainer-family runners. Direct use of either name in processContainer.capabilities is rejected case-insensitively.

📖 Description

• Adds LearningModeCapability classification and effective-mode diagnostics shared by classic AppContainer and BaseContainer. learningModeLogging emits an informational deny-and-record note; permissiveLearningMode emits an always-visible security warning because it allows access.
• Reserves both learning-mode capability names from direct config use. processContainer.learningMode: true is the supported deny-and-record entry point, while --audit is the supported permissive entry point for Windows ProcessContainer only.
• --audit rejects every resolved backend except Windows ProcessContainer before mutating policy or starting a trace. For ProcessContainer it injects permissiveLearningMode, removes learningModeLogging if present, and drives the WPR/ETW permissive-learning-mode trace.
• Keeps internally injected learning-mode capabilities available in both debug and release builds so dedicated entry points have consistent runner behavior.
• Documents the three learning-mode flows in docs/learning-mode/capabilities.md and updates the README warning to describe the reserved capability names and supported entry points.

🔗 References

• Add processContainer.captureDenials config for Windows denial capture #663 (config contract — adds captureDenials + its mode selector that maps onto these capabilities)
• Consume the Windows Learning Mode trace API: FFI loader + capture lifecycle #661 (consume the learning-mode OS API — the capture engine)

Recommended merge order: #663 (config) → #622 (runtime) → integration.

🔍 Validation

• cargo test -p wxc_common -p appcontainer_common — 454 + 141 pass (learning-mode classification / diagnostics tests updated)
• cargo fmt --all -- --check, cargo clippy -p wxc_common -p appcontainer_common -p wxc --all-targets -- -D warnings
• cargo check --workspace --all-targets (confirms the request.audit field removal has no other construction sites)
• npm run test:unit (SDK) — 187 pass
• node scripts/versioning/{check-schema-codegen,check-sdk-types-codegen,validate-configs}.js

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated documentation (if applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)
• If this PR changes Cargo.lock, the dependency-feed-check check passes (see docs/pull-requests.md)

📋 Issue Type

• Bug fix
• Feature
• Task

---

GitHub Actions runs the PR validation build automatically. The ADO pipeline
(MXC-PR-Build) is the Azure version of the PR pipeline, kept in parity with the GitHub
Actions build; it runs on merge to main, and Microsoft reviewers with write access can trigger it
on a PR with /azp run. See docs/pull-requests.md.

If the dependency-feed-check check fails on a new dependency, the crate must be added to
the feed before the PR can pass. See docs/pull-requests.md
for the steps.

Microsoft Reviewers: Open in CodeFlow

[Copilot]

Pull request overview

This PR introduces explicit recognition of two distinct Windows learning-mode capabilities for the AppContainer-based runners (classic AppContainer and BaseContainer), adding diagnostics and documentation so operators can understand whether they are in deny-and-record vs audit/allow-all mode.

Changes:

• Add LearningModeCapability classification plus learning_mode_capability_diagnostics() to emit an informational note for learningMode and a security warning for permissiveLearningMode.
• Replace the prior release-build rejection behavior in the runner with unconditional diagnostics logging.
• Add unit tests for capability classification/diagnostics and add documentation for the two capabilities.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/backends/appcontainer/common/src/appcontainer_runner.rs	Adds learning-mode capability classification + diagnostics and updates runner logging; includes unit tests.
docs/learning-mode/capabilities.md	Documents learningMode vs permissiveLearningMode, their semantics, and how to enable them.

[richiemsft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MGudgin]

This PR has several issues, but my main concerns are the weakening of security guarantees, the default behaviour change for appcontainer and the fact that basecontainer now also has differnet behaviour with no warning to the caller. I'm blocking merge.

[richiemsft]

/azp run

[azure-pipelines]

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

[richiemsft]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[richiemsft]

@MGudgin addressed your comments, left the permissive learning mode available in retail builds based on the teams chat.

[Copilot]

Pull request overview

Copilot reviewed 16 out of 17 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 16 out of 17 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

src/core/wxc_common/src/wire.rs:196

• This rustdoc says permissiveLearningMode may be supplied explicitly, but the parser added in this PR rejects that name case-insensitively (and the next comment says it is reserved). Because this text is propagated into the generated schema and TypeScript wire docs, consumers are told to create a configuration that will always fail parsing. Describe it as internally injected by --audit/denial capture instead, then regenerate the derived files.

    /// AppContainer learning mode (deny-and-record): failed access checks are
    /// logged for diagnostics while the accesses stay denied; containment is
    /// unchanged. Distinct from the allow-all `permissiveLearningMode`
    /// capability, which may be supplied explicitly in `capabilities` or
    /// injected by the `--audit` CLI flag.

[Copilot]

Pull request overview

Copilot reviewed 20 out of 21 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

src/core/wxc_common/src/config_parser.rs:727

• This new rejection breaks checked-in supported configs: tests/configs/hello_world_v060.json:10 and tests/examples/01_hello_world.json:9 both still supply permissiveLearningMode directly, so they now fail parsing instead of running. Please migrate those fixtures (and any compatibility expectations for released 0.6 configs) in this PR so the repository does not continue publishing/running invalid examples.

            if let Some(reserved) = caps.iter().find(|capability| {
                capability.eq_ignore_ascii_case("learningModeLogging")
                    || capability.eq_ignore_ascii_case("permissiveLearningMode")
            }) {

[Copilot]

Pull request overview

Copilot reviewed 23 out of 24 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 23 out of 24 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

src/core/wxc/src/main.rs:1060

• This validation is never reached for state-aware requests: the MxcRequest::StateAware arm calls the diverging run_state_aware_main before execution reaches this block. As a result, wxc-exec --audit can proceed with a Windows Sandbox or IsolationSession lifecycle request while silently skipping both capability injection and PLM tracing, contrary to the ProcessContainer-only contract. Reject --audit in the state-aware arm (or validate it there) before dispatch.

    if cli.audit {
        if let Err(message) = validate_audit_containment(&request.containment) {

docs/learning-mode/capabilities.md:17

• This platform note contradicts the parser behavior added by this PR: direct use of either capability string is rejected case-insensitively on every platform, not ignored outside Windows. Clarify that only the runtime effect of internally injected capabilities is Windows/AppContainer-specific, while direct capability-array use is rejected everywhere.

> **Platform support.** Learning-mode capabilities are **Windows-only** and
> apply to the AppContainer-based backends (classic AppContainer and
> BaseContainer, which share `backends/appcontainer/common`). On other platforms
> the capability strings are ignored.

src/core/wxc_common/src/wire.rs:197

• The canonical schema reference still omits processContainer.learningMode (docs/schema.md:60-63 lists only leastPrivilege and capabilities). Since this changes the field's semantics and exposes it through the public TypeScript config interface, document its deny-and-record behavior there as required for schema-facing changes.

    /// AppContainer learning mode (deny-and-record): failed access checks are
    /// logged for diagnostics while the accesses stay denied; containment is
    /// unchanged. Distinct from the allow-all `permissiveLearningMode`
    /// capability, which is injected internally by the `--audit` CLI flag or
    /// dedicated denial-capture configuration.
    pub learning_mode: Option<bool>,

[richiemsft]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 23 out of 24 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (4)

docs/learning-mode/capabilities.md:98

• block-and-log is not a valid captureDenials.mode; the wire enum accepts block (the default) or allow. Using this heading's value in a config produces a parse error.

2. **App / user-configurable (`captureDenials` block-and-log / `learningModeLogging`).**

docs/learning-mode/capabilities.md:105

• allow-and-log is not a valid captureDenials.mode; the permissive wire value is allow. Please use the actual accepted value here.

3. **Fleet auditing (`captureDenials` allow-and-log / `permissiveLearningMode`).**

docs/learning-mode/capabilities.md:121

• These examples advertise mode strings that the parser rejects. CaptureDenialsMode serializes to "block" and "allow", so the mapping reference should use those exact values.

- `mode: "block-and-log"` (default) maps onto `learningModeLogging`
  (deny-and-record) — the app / user-configurable flow.
- `mode: "allow-and-log"` maps onto `permissiveLearningMode` (allow-and-record)
  — the fleet-auditing flow.

docs/learning-mode/capabilities.md:17

• The capability strings are not ignored on other platforms: config_parser.rs:778-788 rejects either reserved name case-insensitively before backend execution, regardless of target OS. Distinguish unsupported backend behavior from parser behavior so users do not expect such configs to be accepted.

> **Platform support.** Learning-mode capabilities are **Windows-only** and
> apply to the AppContainer-based backends (classic AppContainer and
> BaseContainer, which share `backends/appcontainer/common`). On other platforms
> the capability strings are ignored.

[Copilot]

Pull request overview

Copilot reviewed 23 out of 24 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

src/core/wxc/src/main.rs:1060

• This check is never reached for state-aware requests: the MxcRequest::StateAware branch dispatches through the diverging run_state_aware_main at lines 950–988. As a result, --audit is still silently accepted for Windows Sandbox or IsolationSession lifecycle requests even though neither honors the capability. Reject --audit before state-aware dispatch (or make it conflict with state-aware envelopes) so the ProcessContainer-only contract applies to every request path.

    if cli.audit {
        if let Err(message) = validate_audit_containment(&request.containment) {

docs/learning-mode/capabilities.md:17

• The last sentence is inconsistent with the new parser behavior: reserved capability names are rejected case-insensitively before backend dispatch on every platform, rather than ignored on non-Windows hosts. Distinguish the no-effect behavior of learningMode from the platform-independent rejection of direct capability names.

> **Platform support.** Learning-mode capabilities are **Windows-only** and
> apply to the AppContainer-based backends (classic AppContainer and
> BaseContainer, which share `backends/appcontainer/common`). On other platforms
> the capability strings are ignored.

[richiemsft]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).