Use noninteractive environment tooling in Python agent flows

[Stella Huang (StellaHuang95)]

Use noninteractive environment tooling in Python agent flows

Summary

Route Python language-model environment tools through the compatible Python Environments __pythonTools v1 capability. Agents can configure, query, and install without extension-owned interpreter, folder, or package pickers while retaining VS Code's host approval controls.

This is the consumer half of the paired Python Environments change. Ordinary Python command-palette workflows are not redirected to the private API.

Changes

• Use the private capability for configure_python_environment, get_python_environment_details, get_python_executable_details, and install_python_packages.
• Validate the capability version and all three methods before dispatch. Do not fall back after a private operation starts, returns an error, or is cancelled.
• Describe isolation-by-default configuration and exact pythonPath selection clearly. Propagate global/base installation protection from the provider.
• Forward explicit resource targets and return the effective resource and quoted shell command prefixes. An omitted resource retains the first-workspace-folder default.
• Keep compatible configure/install requests on the private route without a workspace so NO_WORKSPACE cannot be bypassed through global package installation. Read-only no-workspace queries retain their previous route.
• Redirect the hidden create/select LM tools to configuration when the capability is available.
• Keep legacy integration for disabled Environments and a validated, one-warning-per-session compatibility route for missing or incompatible providers.
• Add optional resource targeting to the shared interpreter command for agent compatibility calls. Existing no-argument human callers retain their folder and interpreter pickers.

Compatibility and human impact

Normal selection, creation, Run Python File, debugging, and testing retain their existing entry points. Agent configuration intentionally updates the project selection that those human operations subsequently use.

Chat confirmation/result text changes, and old-provider agent calls can see a new compatibility warning, stricter resource validation, and updated explicit-selection persistence. Compatibility does not provide the new private API's isolation and process-cleanup guarantees.

Validation

• Full ESLint and one-shot TypeScript compilation pass after rebasing onto current upstream main.
• Latest full Windows unit run: 5,425 passing, 34 pending, 8 failures. All eight are the Path/PATH assertions previously reproduced with identical failures on the pristine base; no feature-specific test failed.
• Real VS Code before/after comparisons verified public selection, package install/remove, Run Python File, debugging, unittest discovery/execution, and switching back to global Python.
• Real agent/VSIX checks covered isolated setup, explicit selection, global-install rejection, no-workspace behavior, reload, multi-root, manager-specific flows, and cancellation.
• A baseline agent configuration was observed entering Python-version and interpreter pickers. The compatible private route completed the corresponding setup without those extension-owned choices.

Known findings before merge

• In the old-provider compatibility picker, choosing its nested Create Environment action does not forward the pinned folder into the separate creation command. That subflow is not fully target-pinned.
• Returned private error DTOs are displayed as errors, but BaseTool can emit failed=false because it distinguishes thrown errors rather than returned error results.
• The companion provider has a reproduced package-resolution gap when multiple tracked projects share one Poetry environment.
• Real-chat model decisions, all approval modes, macOS/remote E2E, and third-party callers are not exhaustively verified.

Companion change

Provider PR: microsoft/vscode-python-environments#1900.

The new noninteractive behavior is used only when the provider exposes the compatible capability; there is no hard dependency on a particular extension version.

[Bill Schnurr (bschnurr)]

🔒 Automated review in progress — Bill Schnurr (@bschnurr) is auto-reviewing this PR.

[Bill Schnurr (bschnurr)]

GitHub cannot anchor PR review comments to unchanged lines in the diff. Falling back to a general PR comment for src/client/interpreter/configuration/interpreterSelector/commands/setInterpreter.ts:L591.

Warning · Non-blocking recommendation

📍 src/client/interpreter/configuration/interpreterSelector/commands/setInterpreter.ts:583
Explicit-resource selection pins the workspace, but its nested Create Environment command receives no target. The Skeptic's source-extracted probe confirmed that an interpreter returned from the first root is subsequently persisted for the requested second root. Forward the pinned workspace into nested creation when a resource was supplied, while preserving existing no-resource human behavior.

[unverified]

[Bill Schnurr (bschnurr)]

Result: 🔴 could-not-verify

Verification details

Verification: The relevant tests could not be fully run in the isolated environment; this review is not fully verified.

Summary: [unavailable] Container verification could not start and local execution was not authorized for this PR HEAD: C:\Program Files\RedHat\Podman\podman.EXE --connection pyrx-automation failed: stderr: Error: unable to start container "7d058ee05c97cabbfa922fb77f7750cfa5103d11892c6693d280582952bc3be8": crun: open `memory.max` for writing: No such file or directory: OCI runtime attempted to invoke a command that was not found

Test runs: none recorded.

[Bill Schnurr (bschnurr)]

Approved via Review Center.

[Bill Schnurr (bschnurr)]

Result: 🔴 could-not-verify

Verification details

Verification: The relevant tests could not be fully run in the isolated environment; this review is not fully verified.

Summary: [unavailable] Container verification could not start and local execution was not authorized for this PR HEAD: C:\Program Files\RedHat\Podman\podman.EXE --connection pyrx-automation failed: stderr: Error: unable to start container "5620ecaf0671a5d37dc17d64c8d5f5da91c45ccc603ef769e643db5dd56f2d5e": crun: open `memory.max` for writing: No such file or directory: OCI runtime attempted to invoke a command that was not found

Test runs: none recorded.