Allow trusted host init scripts to preserve direct-script review

まず、組み込み shell ツールの承認および直接スクリプトのレビューのフローを、公開されているセッション単位の shell.initScripts API と併せて追跡します。Bash と PowerShell のホストアクティベーションスクリプトがどのように表現されているかを比較し、そのうえで、ユーザーが制御するスクリプトや読み取り不能なスクリプトに対するレビューを弱めることなく、正確な内容または信頼メタデータをレビュー対象のアクションにどのように結び付けられるかを判断します。明示的に信頼され、更新可能なホストスクリプトに対する安全な直接スクリプトレビューを維持できれば完了です。

Context

VS Code is adopting the public per-session shell.initScripts API so the SDK built-in shell tool can load the user's shell profile and activate the workspace-selected Python environment:

https://github.com/microsoft/vscode/pull/332593

Observed behavior

With no init scripts configured, a direct script invocation can be reviewed using the script and interpreter content under the normal permission flow.

When the same session has any host-provided shell.initScripts entry, the direct script invocation instead requires explicit approval because the shell environment can alter the script action.

This is secure as a conservative default, but it means an SDK consumer cannot opt into a known, host-generated activation script without changing approval behavior for otherwise identical direct script commands.

Ask

Please consider a public SDK contract for trusted host-provided init scripts that preserves safe direct-script review when possible.

Possible shapes include:

• allowing the SDK/runtime to incorporate the exact init-script content into the reviewed action/fingerprint; or
• adding explicit trust metadata for host-generated init scripts, with a conservative default for existing callers.

The behavior must remain secure when init scripts are user-controlled, mutable, unreadable, or otherwise cannot be bound to the reviewed action.

Consumer requirements

• Per-session and updateable, matching shell.initScripts.
• Applies to the built-in shell tool.
• Does not weaken approval for arbitrary or unbound startup scripts.
• Works for Bash and PowerShell host activation scripts.