Codex et Claude Code en lecture seule : analyser et conseiller sans modifier

Vous souhaitez examiner la structure ou les bugs d’un projet existant sans modifier son code, changer les réglages ni installer de logiciels. Préparez à la fois une consigne d’analyse et des autorisations qui limitent les modifications. Le bac à sable en lecture seule de Codex et le mode Plan de Claude Code répondent à des objectifs proches, mais fonctionnent différemment.

Vérifié dans la documentation officielle d’OpenAI et d’Anthropic le 9 octobre 2026. Les exemples de démarrage de cet article n’ont pas été exécutés sur une machine réelle. Nous distinguons le comportement documenté des produits des conditions à vérifier dans votre environnement.

1. Consignes et restrictions d’autorisation

Une demande comme « Analyse les problèmes du parcours de connexion » reste ambiguë : l’agent doit-il corriger ses découvertes ou s’arrêter après son rapport ? Dire « Ne fais aucune modification » transmet votre intention, mais ne retire ni les outils d’édition ni la capacité du shell à écrire.

La documentation de Claude Code explique que les consignes et CLAUDE.md influencent ce que le modèle tente, tandis que le système d’autorisations détermine les actions permises. Si vous inscrivez des interdictions dans le fichier AGENTS.md de Codex, distinguez de même les instructions des autorisations réelles. Source : autorisations de Claude Code.

2. Codex : réglages de l’application, de l’IDE et de la CLI

Desktop : vérifier les restrictions d’écriture dans Settings

Dans l’application de bureau, ouvrez Settings → Configuration depuis le menu de l’application. Le raccourci des réglages est Ctrl+, sous Windows et Cmd+, sous macOS. L’écran officiel Configuration présente séparément Approval policy et Sandbox settings. Les libellés peuvent varier selon la langue et la version.

Sources : écran officiel Configuration, ouvrir les réglages, commande d’autorisations sous le champ de saisie.

Si l’interface est peu claire : utiliser Open config.toml

Ouvrez le fichier de configuration via Settings → Configuration → Open config.toml. Les réglages utilisateur se trouvent généralement dans ~/.codex/config.toml. Avec les anciens réglages de bac à sable, ces valeurs sélectionnent la lecture seule et une politique sans demande d’approbation supplémentaire. Il s’agit d’un exemple de configuration ; lire cet article ne change pas vos réglages.

sandbox_mode = "read-only"
approval_policy = "never"

Les réglages utilisateur affectent aussi l’application, l’extension IDE et la CLI qui lisent la même configuration. Les réglages de projets approuvés dans .codex/config.toml, les options de démarrage et les politiques administrées peuvent aussi s’appliquer. Trouver ces deux lignes ne suffit donc pas à établir qu’elles sont actives. Dans la CLI, /status et /debug-config peuvent afficher les conditions d’exécution et l’origine des réglages. Pour analyser pendant une seule session sans modifier les réglages persistants, utilisez l’exemple CLI ci-dessous.

La nouvelle fonctionnalité Permission profiles est en bêta et offre une autre méthode de configuration, notamment le profil intégré :read-only. En combinaison avec les anciens réglages sandbox_mode ou --sandbox, ceux-ci peuvent avoir priorité ; les politiques administrées introduisent également des exceptions. Vérifiez la méthode déjà utilisée avant d’ajouter les deux. Source : ouvrir le fichier de configuration, priorité des configurations, Permission profiles.

Codex propose aussi /plan pour demander un plan avant la mise en œuvre. Cependant, vérifiez séparément la demande de planification et les restrictions d’écriture des fichiers. Ne supposez pas que les restrictions ou exceptions d’édition du mode Plan de Claude Code s’appliquent aussi à Codex simplement parce que les deux portent le même nom. Source : Codex /plan.

Extension IDE : ouvrir Codex Settings depuis l’icône d’engrenage

En haut de la barre latérale de Codex, utilisez icône d’engrenage → Codex Settings pour vérifier les réglages partagés, et Open config.toml pour les détails. Vérifiez aussi la commande d’autorisations sous le champ de saisie. Les réglages d’extension de l’éditeur sont distincts du fichier config.toml lu par l’agent. Désactiver IDE context, qui fournit les fichiers ouverts, ne révoque pas l’autorisation de l’agent de lire des fichiers. Source : réglages développeur selon le client.

CLI : définir les options pour cette session

Si Codex CLI est déjà disponible, ouvrez un terminal dans le dossier à analyser et démarrez-le comme suit. Vous n’avez pas besoin de réécrire durablement le fichier de configuration. Les politiques administrées de votre organisation et les capacités de votre version de la CLI conservent leur priorité.

codex --sandbox read-only --ask-for-approval never

never ne signifie pas un accès intégral. Le type de bac à sable et la politique d’approbation sont deux réglages distincts. Le tableau officiel des combinaisons d’OpenAI inclut read-only avec never pour lire des fichiers et exécuter des commandes dans ces restrictions. Source : approbations de l’agent et sécurité.

La différence avec on-request

Avec --ask-for-approval on-request, l’agent peut demander l’approbation d’une opération devant s’exécuter hors du bac à sable. Même après un démarrage en lecture seule, approuver cette exécution modifie la limite initiale. « Demander avant de modifier si nécessaire » et « Ne rien modifier cette fois » sont des politiques différentes.

Web, Cloud et Remote : distinguer l’appareil de consultation de l’environnement d’exécution

Le travail sur le Web utilise un environnement d’exécution administré et ne lit pas votre fichier local de configuration Codex. Ajouter les deux lignes ci-dessus sur votre PC ne rend pas, à lui seul, l’exécution Cloud accessible uniquement en lecture. Vérifiez les contrôles de l’interface Cloud et de l’espace de travail. Nous n’avons pas confirmé de procédure de démarrage équivalente rendant tout Cloud accessible uniquement en lecture.

Si vous utilisez Remote pour consulter depuis une autre interface un travail exécuté sur un PC, les réglages pertinents sont ceux de la machine qui exécute réellement les commandes. Ne vous fiez pas aux restrictions du seul appareil de consultation. Consultez quand utiliser Codex localement, via Remote ou dans Cloud. Source : réglages Web et locaux.

3. Utiliser Claude Code uniquement pour analyser et planifier

Claude Desktop : sélectionner Plan près du bouton d’envoi dans l’onglet Code

Ces instructions concernent l’onglet Code de Claude Desktop. Les réglages de Chat et Cowork ne sont pas les modes d’autorisation de Claude Code. Nous utilisons ici les noms de modes de la documentation officielle anglaise ; les libellés réels peuvent varier selon la langue d’affichage et la version.

Plan choisi dans le sélecteur s’applique uniquement à cette session. Les autres choix de mode sont mémorisés par dossier et ont priorité sur permissions.defaultMode dans le fichier de réglages. Si une nouvelle conversation doit aussi se limiter à l’analyse, vérifiez à chaque fois qu’elle affiche Plan. Lire le même fichier de réglages que la CLI ne signifie pas que le choix de mode d’une conversation se transmet à la session suivante. Source : modes Desktop et persistance des choix.

VS Code : sélectionner Plan dans l’indicateur de mode sous le champ de saisie

Ouvrez le panneau de discussion de Claude Code et sélectionnez indicateur de mode sous le champ de saisie → Plan. À partir de v2.1.280, vous pouvez aussi envoyer /plan dans le panneau pour changer de mode. Si le plan s’ouvre comme document Markdown, lisez-le comme résultat d’analyse sans approuver sa mise en œuvre.

Selon la spécification officielle actuelle, le réglage de l’espace de travail pour claudeCode.initialPermissionMode est ignoré. Cela diffère du comportement antérieur à v2.1.225. Choisir Plan dans la discussion ne concerne également que cette conversation. Ne supposez pas qu’inscrire permissions.defaultMode dans le fichier .claude/settings.json du projet change nécessairement le mode initial de VS Code. Vérifiez la priorité entre le réglage du mode initial de l’extension, le dernier mode normal choisi, les réglages administrés, les réglages utilisateur et les autres configurations applicables.

Surveillez aussi les fichiers non enregistrés. Le réglage d’extension claudeCode.autosave enregistre les modifications de l’éditeur avant que Claude lise ou écrive. Distinguez les modifications du code source par l’IA des fichiers enregistrés par l’éditeur. Joindre automatiquement les fichiers ouverts est également distinct de limiter leur accès. Source : commandes de mode VS Code, réglages d’extension et priorité.

Commandes Web, mobile et JetBrains

Les modifications ordinaires de fichiers sont préapprouvées dans Cloud : ne le traitez donc pas comme Manual. Sélectionnez explicitement Plan pour l’analyse et demandez à l’agent de s’arrêter après son rapport au lieu de passer à la mise en œuvre. Le fonctionnement des approbations Cloud ne signifie pas que les fichiers sources peuvent être réécrits sans condition en Plan. Source : changer de mode selon l’interface, modes Cloud.

CLI : démarrer en Plan sans approuver la mise en œuvre

Démarrez Claude Code CLI en mode Plan avec l’option suivante. Le mode Plan ordinaire lit les fichiers, examine la structure et les problèmes et planifie les changements proposés. Les modifications par les outils d’édition du code source sont normalement bloquées, mais des fichiers de plan sont créés.

claude --permission-mode plan

Les commandes shell dans Plan ne sont pas systématiquement limitées à la lecture seule. Si le mode auto est disponible et que useAutoModeDuringPlan est activé, un classificateur peut les examiner et les autoriser. Lorsque auto est indisponible, entre autres cas, les commandes hors de l’ensemble intégré de commandes en lecture seule demandent une approbation. Source : Plan dans Permission modes.

Si vous ne souhaitez ni commandes shell ni outils d’édition

Si lire le code et examiner sa structure suffit, utilisez --tools pour limiter les outils intégrés. Cet exemple restreint les outils d’examen des fichiers à Read, Glob et Grep et interdit également les outils MCP. EndConversation reste disponible pour terminer la conversation. Les capacités d’analyse sont réduites par rapport à Plan ordinaire : les vérifications nécessitant l’exécution de commandes deviennent indisponibles.

claude --permission-mode plan --tools "Read,Glob,Grep" --disallowedTools "mcp__*"

Ne remplacez pas cette option par --allowedTools. Cette option désigne les outils autorisés sans confirmation ; elle ne limite pas les outils disponibles à cette liste. De plus, --tools seul ne limite pas MCP : une option distincte est nécessaire. Source : référence CLI.

Desktop ne propose pas de commandes d’interface par session équivalentes aux options CLI --allowedTools ou --disallowedTools. Les règles d’autorisation des fichiers de réglages s’appliquent, mais le bouton Plan seul ne produit pas les mêmes restrictions que cet exemple limitant les outils. Source : capacités Desktop et CLI.

Cet exemple ne rend pas tout votre PC accessible uniquement en lecture, y compris les données enregistrées par l’application ou les réglages et hooks chargés. Lors de l’ouverture d’un projet inconnu, vérifiez séparément les hooks, plugins et connexions externes existants. Pour un fonctionnement plus strict, --restricted, disponible depuis v2.1.248, modifie davantage que les outils : il change notamment les réglages chargés. Ce n’est pas un autre nom de Plan conservant votre environnement habituel à l’identique.

Pour gérer durablement les autorisations des outils, consultez les réglages allow, ask et deny de Claude Code. Pour isoler Bash, consultez la configuration du bac à sable et ses limites. Une isolation qui permet par défaut les écritures dans l’espace de travail poursuit un autre objectif qu’une simple analyse.

4. Une consigne d’analyse prête à l’emploi

Une fois les autorisations en place, demandez à l’agent de s’arrêter après son rapport. Définir le périmètre de l’analyse et le résultat qui termine la tâche plus précisément que « Corrige ceci » ou « Améliore ceci » réduit les malentendus menant à la mise en œuvre.

Pour cette tâche, analyse uniquement l’état actuel et donne des conseils. Ne mets rien en œuvre.

Périmètre : parcours de connexion et limites d’autorisation de ce projet.
Autorisé : lire les fichiers sources accessibles et expliquer la structure et les problèmes.
Interdit : créer, modifier ou supprimer des fichiers ; changer des réglages ; ajouter des dépendances ;
           builds, tests, opérations sur la base de données, commits, pushes, déploiements
           ou modifications des services externes.
           Ne pas élargir les autorisations pour exécuter des hooks ou scripts.

Livrables :
1. Le parcours de traitement, avec les fichiers examinés et les numéros de ligne
2. Les preuves, l’impact et la priorité de chaque problème potentiel
3. Les améliorations proposées sans les exécuter et les vérifications nécessaires avant mise en œuvre
4. Les questions que la lecture seule ne résout pas et les vérifications non effectuées

Même si une modification est nécessaire, arrête-toi à la recommandation sans l’exécuter.
Termine la tâche après avoir remis le rapport d’analyse.

Même si vous approuvez une amélioration proposée, vous pouvez répondre dans la conversation d’analyse : « Conserve cette approche comme possibilité. Ne la mets pas en œuvre. » Pour continuer, démarrez une conversation de développement distincte avec des périmètres redéfinis pour les changements, les tests et la publication. Les restrictions d’analyse restent ainsi cohérentes avec l’objectif de la tâche.

5. Les vérifications avant et après

Ne vous arrêtez pas à « Le modèle a dit qu’il n’a rien changé ». Il n’est pas non plus nécessaire d’essayer d’écrire dans le code à protéger simplement pour vérifier qu’il est inchangé. Commencez par l’interface, les explications de configuration et les différences existantes, puis notez les incertitudes restantes.

Si le projet utilise Git, comparer les différences

Par exemple, ces commandes montrent les fichiers modifiés et un résumé des différences indexées et non indexées. Vérifiez les deux avant et après l’analyse afin de ne pas confondre vos modifications préexistantes avec celles de l’IA. Cet exemple suppose que le dépôt cible utilise déjà Git.

git status --short
git diff --stat
git diff --cached --stat

Ces commandes ne prouvent pas que rien n’a changé nulle part. git diff n’affiche pas les fichiers non suivis, et ces vérifications ne couvrent pas tous les fichiers ignorés, les emplacements hors de l’espace de travail, les bases de données ou les services externes. Les différences finales ne révèlent pas non plus une opération qui a modifié puis restauré quelque chose. Dans le rapport, distinguez ce que vous avez vérifié de ce que vous n’avez pas vérifié. Documentation officielle Git : git status, git diff.

6. Vérifications impossibles et risques restants

Les tests et builds peuvent aussi écrire des fichiers

Même sans modifier le code, les tests peuvent écrire des fichiers temporaires ou des instantanés, les builds créer des artefacts et les gestionnaires de paquets écrire des caches ou dépendances. Ne supposez pas que « seulement lancer les tests » ne change rien. Un échec sous des restrictions de lecture seule peut être leur résultat voulu plutôt qu’un bug.

Si un rapport conclut qu’une autorisation pourrait être contournée sous certaines conditions, l’étape suivante peut être un plan de reproduction dans un environnement de vérification distinct. Améliorer une analyse n’exige pas d’autoriser immédiatement les écritures dans une base de production ou une machine contenant des secrets. Séparer ce que l’inspection statique peut établir de ce qui nécessite une exécution rend le rapport plus utile pour décider.

Les restrictions réseau de Codex distinguent également les communications des commandes exécutées dans le bac à sable du trafic de service pour les modèles, l’authentification et d’autres usages. Démarrer en lecture seule ne garantit pas que les informations lues ne seront pas envoyées au modèle ou utilisées pour l’entraînement. Source : portée de Permissions. Pour bloquer la lecture des secrets, consultez fichiers secrets et autorisations de Codex. Pour les réglages d’entraînement et de conservation, consultez utilisation pour l’entraînement et confidentialité de ChatGPT et Codex.

Résumé

Pour Codex, définissez la lecture seule et une politique d’approbation. Pour Claude Code, vérifiez les conditions de démarrage de Plan et limitez les outils disponibles si nécessaire. Donnez ensuite une consigne qui termine la tâche à la remise du rapport. Les deux outils permettent de séparer analyse et exécution des modifications.

Si des restrictions strictes laissent des questions sans réponse, acceptez la liste des vérifications non effectuées et une proposition de validation supplémentaire plutôt que de passer facilement à l’accès intégral. Les contrôles des informations lisibles, outils externes et données enregistrées par l’application nécessitent une conception distincte de l’interdiction de modifier le code source.

FAQ

Demander « Analyse uniquement » limite-t-il l’agent à la lecture seule ?

Cela transmet l’objectif, mais ne change pas les capacités d’édition réelles ni les autorisations des commandes. Avec la consigne, utilisez le bac à sable de Codex ou Plan et les restrictions d’outils de Claude Code et vérifiez leurs limites exactes.

Claude Code Plan garantit-il qu’aucun fichier ne change ?

Non. Il bloque normalement les modifications du code source, mais crée des fichiers de plan. La documentation officielle précise aussi que les restrictions de Plan ne sont pas appliquées dans les sessions de terminal interactif où le contournement est disponible. Ce mode n’interdit pas toute écriture sur votre PC.

La politique d’approbation « never » de Codex signifie-t-elle un accès sans restriction ?

Elle signifie aucune demande d’approbation ; elle ne désactive pas le bac à sable. Associée à read-only, elle permet à l’agent d’analyser dans ces restrictions. Distinguez cela d’un démarrage avec accès intégral.

Une analyse en lecture seule suffit-elle à terminer une revue de sécurité ?

Non. Les problèmes potentiels repérés en lisant le code diffèrent des résultats reproduits par exécution. Les conclusions restent limitées si la configuration, l’environnement d’exécution ou les services dépendants ne peuvent être vérifiés. Rapportez les preuves et inconnues, puis planifiez toute démonstration nécessaire dans un environnement de vérification distinct.

Ask for approval dans l’application Codex empêche-t-il les modifications ?

Pas à lui seul. La politique d’approbation et les restrictions d’écriture sont distinctes. Vérifiez Configuration et les autorisations actives, puis utilisez des restrictions équivalentes à read-only pour une simple analyse.

Si je sélectionne Plan une fois dans Claude Desktop ou VS Code, s’appliquera-t-il la prochaine fois ?

Plan choisi dans le sélecteur ne concerne que cette conversation ou session. Vérifiez l’indicateur chaque fois. Dans VS Code, le réglage utilisateur claudeCode.initialPermissionMode permet de définir le mode initial.