Bac à sable Windows

Utilisez Codex sur Windows avec l’application de bureau ChatGPT native, la CLI ou l’extension pour IDE.

Sur Windows, l’application de bureau ChatGPT prend notamment en charge les discussions en parallèle, les arbres de travail, les tâches planifiées, les fonctionnalités Git, le navigateur intégré, les aperçus de fichiers, les plugins et les skills.

L’application peut s’exécuter directement dans PowerShell avec un bac à sable Windows, sans nécessiter WSL ni machine virtuelle. Vous pouvez ainsi utiliser Codex dans vos workflows Windows natifs tout en limitant son accès au système de fichiers et au réseau.

Pour une installation en entreprise, consultez le guide de déploiement sur Windows.

Set up Agent sandbox to continueSet up

Ask for follow-up changes

6 SolMedium

LocalDefault permissionsmaster

Utilisez l’application de bureau ChatGPT sur Windows

Travaillez sur plusieurs projets, menez des discussions en parallèle et consultez les résultats au même endroit avec l’application native pour Windows.

Codex prend en charge trois implémentations du bac à sable Windows :

• mxc : le bac à sable recommandé sur les appareils Windows compatibles. Il utilise l’isolation native des processus. Sa configuration ne nécessite ni approbation d’un administrateur, ni comptes Windows supplémentaires, ni règles de pare-feu locales.
• elevated : la solution de repli à privilégier parmi les implémentations historiques lorsque MXC est indisponible ou désactivé. Sa configuration nécessite l’approbation d’un administrateur. Les commandes s’exécutent ensuite dans le bac à sable sans privilèges d’administrateur.
• unelevated : une solution de repli historique à utiliser lorsque la configuration avec élévation de privilèges est impossible et que la stratégie de votre organisation le permet. Elle offre une isolation réseau plus faible que elevated et ne permet pas d’interdire la lecture de chemins spécifiques.

Configuration du bac à sable Windows

Le bac à sable Windows applique les autorisations d’accès au système de fichiers et au réseau en vigueur aux commandes et à leurs processus enfants. Le profil d’autorisations détermine les chemins accessibles en lecture ou en écriture ainsi que la possibilité d’accéder au réseau. La stratégie d’approbation détermine séparément quand Codex demande à exécuter des commandes avec des droits supplémentaires. Consultez la documentation sur le bac à sable et les approbations.

Activation de MXC

Pour les comptes grand public, l’application de bureau privilégie automatiquement MXC si l’appareil le prend en charge. Pour les déploiements en entreprise ou l’utilisation autonome de la CLI, vous pouvez activer ce comportement avec la configuration ci-dessous.

Dans config.toml, ajoutez :

[features]
prefer_mxc = true

Avec prefer_mxc = true, Codex utilise MXC pour les commandes Windows si l’appareil le prend en charge et si la stratégie l’autorise. Dans le cas contraire, Codex suit la procédure existante de sélection et de configuration du bac à sable historique.

Si la compatibilité des appareils ou les stratégies varient au sein de votre entreprise, conservez pour windows.sandbox l’implémentation historique autorisée par votre organisation, elevated ou unelevated, comme solution de repli.

Les administrateurs peuvent distribuer cette configuration par défaut ou imposer features.prefer_mxc = true dans requirements.toml. Dans les deux cas, le recours à une implémentation historique reste possible. Consultez la documentation sur la configuration gérée pour comprendre la différence entre les paramètres par défaut et les exigences.

Désactivation de MXC

Pour empêcher l’utilisation de MXC dans votre organisation, ajoutez ce qui suit au fichier requirements.toml géré :

[windows]
allow_mxc = false

Ce paramètre bloque à la fois la sélection automatique de MXC et sa sélection explicite avec windows.sandbox = "mxc". Les paramètres et exigences existants du bac à sable historique continuent de s’appliquer.

Compatibilité avec MXC

L’hôte doit déjà disposer des fonctionnalités Microsoft Execution Containers (MXC) requises, que Microsoft déploie progressivement sur les appareils Windows 11. Microsoft a introduit l’isolation des processus par MXC dans Windows 11 24H2 (build 26100.9278) et 25H2 (build 26200.9278). Utilisez la commande ci-dessous pour vérifier si votre appareil prend en charge MXC.

À partir de la version 0.162.0 de Codex CLI, vous pouvez tester MXC pour une seule commande sans modifier le choix de bac à sable enregistré. Depuis le répertoire de votre projet, exécutez :

codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODE

La sortie attendue est MXC_OK, avec un code de sortie de 0. Ce test vérifie que la commande démarre avec le profil d’autorisations de l’espace de travail et les exigences gérées.

La sélection explicite de windows.sandbox = "mxc" échoue si les fonctionnalités natives requises sont indisponibles ou si la stratégie bloque MXC.

Tenez compte des limites de compatibilité suivantes :

• La gestion du réseau exige que le paramètre allow_local_binding = true soit effectivement appliqué. MXC autorise les connexions vers et depuis les services de l’interface de bouclage de l’hôte. Les règles de domaine du proxy s’appliquent toujours au trafic qui transite par celui-ci, mais le proxy n’effectue plus ses vérifications supplémentaires sur les destinations situées dans des réseaux privés.
• Les processus enfants encore actifs s’arrêtent lorsque la commande au premier plan se termine. Testez les workflows qui dépendent de serveurs de développement lancés en mode détaché.
• Comme sur Linux et WSL, les motifs glob d’interdiction de lecture s’appliquent aux fichiers qui correspondent à ces motifs au démarrage de chaque processus dans le bac à sable. Les fichiers correspondants créés par la suite restent lisibles par ce processus si ses autres autorisations le permettent. Pour les shells, scripts, outils de surveillance et serveurs de développement de longue durée, cette liste reste figée pendant la durée de vie du processus concerné, et non pendant toute la session Codex. Consultez la documentation sur le moment où les motifs glob d’interdiction de lecture sont évalués.

Configuration d’une solution de repli historique

Sélectionnez l’implémentation de repli dans config.toml :

[windows]
sandbox = "elevated" # or "unelevated"

elevated est la solution de repli historique à privilégier. Elle utilise des comptes dédiés au bac à sable dotés de privilèges réduits, limite l’accès au système de fichiers, applique des règles de pare-feu et modifie la stratégie locale selon les besoins des commandes exécutées dans le bac à sable.

Comme MXC, elevated recense les fichiers correspondant aux motifs glob d’interdiction de lecture au démarrage de chaque processus dans le bac à sable. Les fichiers correspondants créés par la suite restent lisibles par ce processus si ses autres autorisations le permettent. Consultez la documentation sur le moment où les motifs glob d’interdiction de lecture sont évalués pour en connaître les conséquences sur les processus de longue durée.

unelevated est une solution de repli historique. Elle exécute les commandes avec un jeton Windows restreint dérivé de votre compte utilisateur actuel et limite l’accès au système de fichiers au moyen de listes de contrôle d’accès (ACL). Pour le mode hors connexion, elle utilise des contrôles au niveau de l’environnement à la place de la règle de pare-feu dédiée au compte hors connexion. Elle offre une isolation réseau plus faible que elevated et ne permet pas d’interdire la lecture de chemins spécifiques. Elle reste toutefois utile lorsque la stratégie locale ou celle de l’entreprise bloque la configuration nécessitant l’approbation d’un administrateur.

Utilisez MXC si l’appareil le prend en charge et si la stratégie l’autorise. Sinon, privilégiez elevated et gardez unelevated comme deuxième solution de repli.

Les administrateurs d’entreprise peuvent limiter les implémentations historiques du bac à sable que Codex est autorisé à utiliser dans requirements.toml :

[windows]
allowed_sandbox_implementations = ["elevated"]

Cet exemple autorise elevated et empêche le recours à unelevated. Il ne limite pas l’utilisation de mxc lorsque MXC est disponible. Les autres exigences gérées relatives aux autorisations et au réseau continuent de s’appliquer. Pour autoriser les deux implémentations historiques, indiquez les deux valeurs. Codex privilégie elevated lorsqu’aucun mode n’est sélectionné.

Consultez la référence de requirements.toml pour connaître les valeurs prises en charge. Pour bloquer également MXC, utilisez l’exigence distincte windows.allow_mxc.

Par défaut, les deux modes historiques du bac à sable utilisent également un bureau privé pour renforcer l’isolation de l’interface utilisateur.

Préparation du bac à sable historique avec élévation de privilèges par le service informatique

Pour les employés qui ne disposent pas de droits d’administrateur local, le service informatique peut installer la CLI et préparer le bac à sable avec élévation de privilèges avant qu’ils ne lancent Codex. Depuis un processus de déploiement disposant de privilèges élevés, exécutez :

codex sandbox setup --elevated --user 'DOMAIN\alice' --codex-home 'C:\Users\alice\.codex'

Remplacez l’identité et le chemin de l’exemple par l’identité Windows de l’employé et le chemin de son répertoire CODEX_HOME. La commande lit la configuration de cet utilisateur, prépare le bac à sable et enregistre windows.sandbox = "elevated". L’employé lance ensuite Codex depuis un terminal sans élévation de privilèges.

Autorisations du bac à sable

Prise en charge selon la version de Windows

Autres points à vérifier dans votre environnement :

• winget devrait être disponible. S’il manque, mettez Windows à jour ou installez le Gestionnaire de packages Windows avant de configurer Codex.
• La configuration du bac à sable historique elevated nécessite l’approbation d’un administrateur.
• Certains appareils gérés en entreprise bloquent les étapes de configuration requises, même si la version du système d’exploitation est compatible.
• MXC nécessite en outre les fonctionnalités natives décrites dans la section Compatibilité avec MXC. Le tableau ne suffit pas à déterminer si MXC est disponible sur un appareil donné.

Vérification des accès en lecture du bac à sable

Lorsqu’une commande ne parvient pas à lire un répertoire, vérifiez le profil d’autorisations actif, les exigences gérées et les autorisations de fichiers Windows. Dans la CLI, utilisez /status et /debug-config pour examiner la session active et sa configuration. Si une restriction gérée est en cause, demandez à votre administrateur de la vérifier plutôt que de désactiver le bac à sable.

Utilisez le bac à sable Windows natif par défaut. Choisissez WSL si vous avez besoin d’outils natifs Linux, si vous travaillez déjà dans WSL2 ou si les implémentations Windows natives disponibles ne répondent pas à vos besoins.

Dépannage et FAQ

Pour dépanner un poste Windows géré, commencez par relever le mode du bac à sable natif, la version de Windows et les éventuelles erreurs de stratégie affichées par Codex. Pour MXC, vérifiez la compatibilité et la stratégie réseau effectivement appliquée. Les problèmes liés au bac à sable historique peuvent provenir de sa configuration, des droits d’ouverture de session ou des autorisations du système de fichiers.