概要

Windows専用の syscall.SysProcAttr にジョブオブジェクト、コンソール、デスクトップ、AppContainer、そして実験的サンドボックスといった最新のプロセス生成機能を制御するフィールドを追加し、os/exec からWindowsの高度なプロセス分離・サンドボックス機能を安全に利用できるようにする提案です。

ステータス変更

（新規提出） → active
2026年7月29日、@aclements によりproposal reviewの「active」カラムに追加され、今後は毎週のproposal reviewミーティングで審査される段階に入りました。issue自体は7月15日に提出され、実装CL（CL 801640）も既に用意されている状態です。

技術的背景

現状の問題点

パッケージ syscall は原則として凍結（frozen）方針ですが、os/exec 経由のプロセス生成に関わる部分は例外として扱われています。現状、Windowsでジョブオブジェクトへの参加、専用コンソール/デスクトップの指定、AppContainerによるサンドボックス化などを行うには、syscall・os・os/exec の内部ロジックをまるごとフォークして自前実装する必要があり、非常にコストが高い状況でした。

提案された解決策

SysProcAttr（Windows版）に以下のフィールドを追加します。

Jobs         []Handle       // 非nilなら、これらのジョブオブジェクトに所属させて起動
Console      Handle         // 非ゼロなら、指定のコンソールに接続して起動
Desktop      string         // 非空なら、指定デスクトップ上で起動
AppContainer *AppContainer  // 設定時、AppContainerプロセスとして起動
Sandbox      *Sandbox       // 非nilなら、実験的サンドボックス内で起動

AppContainer は Windows の SECURITY_CAPABILITIES 構造体を型安全なGoの形（SID + []SIDAndAttributes）で表現したものです。Sandbox は Microsoftが2026年5月に公開した実験的API Experimental_CreateProcessInSandbox（microsoft/mxc が利用）に対応するためのもので、Identity string と FlatBuffers エンコード済みの Spec []byte を持ちます。仕様（スキーマ）の詳細な組み立てはこのproposalの範囲外とし、golang.org/x/sys/windows 側で今後追随する想定です。

これによって何ができるようになるか

• サンドボックス化されたエージェント実行環境の構築（AppContainerや将来のExperimental_CreateProcessInSandboxを利用した権限制限）
• 子プロセスをまとめて確実に終了させるためのジョブオブジェクト管理（Windowsにはプロセスグループがないため、Job Objectが唯一の代替手段）
• テストツールや仮想デスクトップ環境でのGUIアプリケーションの分離実行、専用コンソールへの接続

コード例

// Before: AppContainerで子プロセスを起動するには syscall/os/exec を丸ごとフォークする必要があった
// （HashiCorp Nomadチームの実例: STARTUPINFOEX を自前構築し標準ライブラリのコードを大量に複製）
// After: 新フィールドで直接指定できる
cmd := exec.Command("child.exe")
cmd.SysProcAttr = &syscall.SysProcAttr{
    AppContainer: &syscall.AppContainer{
        SID:          appContainerSID,
        Capabilities: capabilities,
    },
    Jobs: []syscall.Handle{jobHandle}, // KILL_ON_JOB_CLOSE 設定済みのジョブに所属させる
}
cmd.Run()

議論のハイライト

• 提案者 @rsc は、Jobs/Console/Desktop/AppContainer は既存の関連proposal（#65611, #79927, #42836）を統合・整理したものであり、syscall の型安全性を維持しつつ最小限のAPI追加で実現できると説明しています。
• Sandbox フィールドは提出後の7月28日に追加され、Microsoftの実験的API（現状Windows実機では未有効化）に事前対応する狙いがあります。次のGoリリース（2027年2月）を見据え、後から慌てて追加するリスクを避けたいという意図です。
• @magical は「まだ実験段階（experimental）であり将来変更・廃止される可能性が明記されたAPIを標準ライブラリに先取りして取り込むのは時期尚早」と強く異議を唱え、必要なら一時的にforkして使うべき、機能がGA（一般提供）されてから改めてproposalを出せばよいと主張しました。
• これに対し@rscは、(1) 最悪でも「使われなくなる1フィールド」が残るだけで実害は小さい、(2) MicrosoftがWindows 11に既に実装を出荷し公式プロジェクト（mxc）でも使用・発表済みであることから関数シグネチャレベルの破壊的変更は考えにくい、(3) サンドボックス仕様本体（FlatBuffers []byte）はバージョン管理を呼び出し側とx/sys/windowsに委ねる設計にしている、と反論。またmxcチームへの問い合わせで「Windows Insider Previewで既に利用可能、年内にGA予定」との回答を得たことも追加説明しています。
• @magical は最終的に「Sandbox以外の追加には異論なし」と明言しており、Sandbox フィールドの是非が今後のレビューの争点として残っている状態です。