Opposing user/workspace integration settings crash Python activation #1895

Environment data

Reproduced on both macOS and Linux:

• Workspace: reproduced in a minimal single-root workspace; also observed in Linux multi-root cases.
• Regression / last known working version: unknown.
• Tests used fresh, isolated extension development/test windows. There was no debugger attached in the macOS repetitions or the three Linux repeat runs. Manual reproduction in an ordinary non-development window remains to be checked.

Repro Steps

1. Install the compatible Python and Python Environments versions above in a disposable profile.

2. Configure user settings:

   {
       "python.useEnvironmentsExtension": false,
       "workbench.enableExperiments": false,
       "python.experiments.enabled": false,
       "telemetry.telemetryLevel": "off"
   }

3. Open a trusted single-folder Python project whose workspace settings contain:

   {
       "python.useEnvironmentsExtension": true
   }

4. Open a Python file in a fresh window and allow normal activation. Do not call the integration-decision function or force extension activation as an observation probe.

5. Inspect the Python output / extension-host log and the exported APIs.

Expected behavior

The higher-precedence workspace value resolves to true. Python and Environments should agree on the activation/API contract, and Python activation should not crash.

If integration cannot initialize, that condition should be handled explicitly rather than consuming undefined exports. This is not a request to overwrite explicit settings or change VS Code configuration precedence.

Actual behavior

• The effective setting is true, and Environments is visible in Python's extension host.
• Environments exports no API.
• Python activation throws while accessing onDidChangeEnvironment on undefined.
• Both extensions can report isActive === true despite exposing no API; isActive alone is not a successful-initialization check.
• Reproduced in 2/2 clean macOS profiles and 4/4 clean Linux profiles. Both macOS runs and two Linux repeats were single-root.
• Clean macOS controls with user integration true and no opposing false setting activate successfully and execute Python normally.

Logs

Python output and extension-host error:

extension activation failed [TypeError: Cannot read properties of undefined (reading 'onDidChangeEnvironment')

The Linux failure additionally logged:

getActivationTelemetryProps() failed. [Error: No matching bindings found for serviceIdentifier: Symbol(IComponentAdapter)

Additional context

The behavior is consistent with mismatched gates: Python's integration decision uses the effective setting, while Environments' activation policy rejects an explicit false even when a higher-precedence true overrides it. Python's API loader then assumes extension.exports is usable and subscribes to onDidChangeEnvironment without validating the exports.

This may require coordinated changes with microsoft/vscode-python; filing here to track the integration contract.

Related but distinct: #1778 concerns default-false activation/ownership disagreement. This report concerns an explicit opposing-scope configuration that crashes Python activation.

Telemetry and both experiment controls remained off. No production telemetry or population-level causality claim is involved.