3 façons de lancer Codex en ligne de commande sans vérifier les autorisations : codex –yolo est l’équivalent de –dangerously-skip-permissions dans Claude Code

Après avoir pris l’habitude de lancer Claude Code avec claude --dangerously-skip-permissions, on se pose souvent la première question en passant à l’interface en ligne de commande Codex d’OpenAI : quel est l’équivalent pour travailler sans demander d’approbation ? La réponse est simple : codex –yolo. La commande complète est codex --dangerously-bypass-approvals-and-sandbox.

Cet article ne se contente pas de vous donner une commande à retenir. Nous allons détailler les limites d’accès, les cas d’usage et les bonnes pratiques de sécurité des trois modes de lancement. Nous verrons aussi comment connecter un modèle via APIYI apiyi.com.

L’essentiel : à la fin de cet article, vous saurez choisir les bons paramètres pour votre environnement de développement : moins de clics sur « Confirmer », sans pour autant laisser l’IA agir là où elle ne devrait pas.

Points clés sur l’option –yolo de la ligne de commande Codex

Commençons par comparer les commandes qui ouvrent tous les accès dans les deux outils :

Explication du paramètre complet et de sa version courte dans Codex CLI

codex --dangerously-bypass-approvals-and-sandbox et codex --yolo ont exactement le même effet : la seconde commande est simplement une version abrégée de la première. Une fois cette option activée, Codex ne vous demande plus d’approbation à chaque étape et n’est plus limité par le bac à sable. Il peut exécuter des commandes, modifier des fichiers et accéder au réseau directement.

Les deux mots clés du nom complet méritent votre attention. « approvals » désigne les approbations, autrement dit la question de savoir si Codex doit vous demander votre accord avant chaque commande. « sandbox » désigne le bac à sable, c’est-à-dire les fichiers accessibles à Codex et ses capacités d’accès au réseau. Le nom complet précise que cette option lève deux barrières de protection, et pas une seule.

On peut résumer la différence avec Claude Code ainsi : --dangerously-skip-permissions de Claude Code correspond principalement à la suppression des demandes de confirmation, tandis que --yolo de Codex supprime aussi le bac à sable. Cette option ouvre donc davantage l’accès qu’on pourrait le croire à la lecture de son nom.

Comparaison de 3 modes de lancement de Codex en ligne de commande

Au quotidien, Codex s’utilise le plus souvent selon l’un de ces 3 modes de lancement. Leur différence tient à deux questions : faut-il demander une approbation et le bac à sable est-il toujours actif ?

codex est le mode le plus prudent. Il convient pour découvrir un projet inconnu ou lorsque vous souhaitez garder le contrôle à chaque étape. codex --full-auto se situe entre les deux : les opérations dans l’espace de travail s’exécutent automatiquement, tout en restant soumises aux restrictions du bac à sable. C’est le mode qui répond le mieux au besoin de « laisser l’IA travailler seule sans la laisser sortir du répertoire du projet ». codex --yolo déverrouille toutes les permissions. Il convient lorsque l’environnement est suffisamment isolé et que les conséquences d’une erreur sont limitées.

Si vous souhaitez que les tâches s’exécutent automatiquement, comme avec Claude Code, sans désactiver le bac à sable dès le départ, commencez par codex --full-auto. Une fois que vous avez vérifié que la tâche est fiable et que l’environnement est sûr, vous pourrez envisager --yolo.

Par ailleurs, vous pouvez ajuster séparément la stratégie d’approbation et le mode de bac à sable de Codex. Inutile de lever les deux garde-fous à la fois. Pour connaître les valeurs disponibles, consultez la sortie de codex --help sur votre machine et la documentation officielle de configuration : elles peuvent varier selon les versions.

Prise en main rapide de Codex –yolo

Exemple de démarrage minimal

Dans le terminal, placez-vous dans le répertoire de votre projet et lancez directement :

# 完整写法
codex --dangerously-bypass-approvals-and-sandbox

# 等价的简写
codex --yolo

Si vous passez souvent d’un mode à l’autre, vous pouvez ajouter deux alias à votre fichier de configuration shell pour éviter de les saisir à chaque fois :

# 加入 ~/.zshrc 或 ~/.bashrc
alias cx="codex"
alias cxa="codex --full-auto"
alias cxy="codex --yolo"

Vous pouvez choisir d’autres noms pour les alias. Pour celui de --yolo, choisissez un nom bien visible afin de vous rappeler que vous êtes en mode totalement débridé.

Configurer l’accès aux modèles via APIYI

Codex permet de configurer des fournisseurs de modèles personnalisés. Pour appeler plusieurs modèles avec une seule clé API, vous pouvez le connecter à l’interface compatible avec OpenAI d’APIYI, disponible à l’adresse https://api.apiyi.com/v1.

Voici un exemple de configuration pour ~/.codex/config.toml :

# 自定义模型提供方示例，字段名以你所用 Codex 版本的官方配置文档为准
[model_providers.apiyi]
name = "APIYI"
base_url = "https://api.apiyi.com/v1"  # 使用 APIYI 统一接口
env_key = "APIYI_API_KEY"

Une fois la configuration terminée, définissez la clé API dans la variable d’environnement APIYI_API_KEY, puis indiquez apiyi comme fournisseur par défaut dans la configuration. Les noms de champs et la syntaxe peuvent varier selon les versions : pensez à vérifier la documentation officielle avant de commencer.

import os
import openai
from typing import Optional


def check_connection(
    prompt: str = "回复 OK 即可",
    model: str = "gpt-4o-mini",
    system_prompt: Optional[str] = None,
) -> str:
    """
    用最小请求验证 API Key 与 base_url 是否可用

    Args:
        prompt: 用户输入
        model: 模型名称
        system_prompt: 可选的系统提示词

    Returns:
        模型响应内容或错误信息
    """
    client = openai.OpenAI(
        api_key=os.environ.get("APIYI_API_KEY", "YOUR_API_KEY"),
        base_url="https://api.apiyi.com/v1",  # APIYI 统一接口
    )

    messages = []
    if system_prompt:
        messages.append({"role": "system", "content": system_prompt})
    messages.append({"role": "user", "content": prompt})

    try:
        response = client.chat.completions.create(
            model=model,
            messages=messages,
            max_tokens=50,
        )
        return response.choices[0].message.content
    except Exception as e:
        return f"Error: {str(e)}"


if __name__ == "__main__":
    print(check_connection())

Conseil : obtenez un crédit d’essai gratuit sur APIYI, apiyi.com, et testez d’abord codex --full-auto sur un petit projet avant de décider si vous avez besoin de --yolo. Une seule clé API vous permet d’appeler les principaux modèles, comme OpenAI, Claude et Gemini, et de comparer leurs performances lors de l’exécution automatique de tâches.

Quand utiliser Codex –yolo : choisir selon le scénario

Le choix du mode de lancement dépend de trois facteurs : l’environnement est-il fiable, les modifications peuvent-elles être annulées et la tâche nécessite-t-elle une connexion à Internet ? Voici quelques recommandations pour les scénarios courants :

La logique derrière ce tableau est simple : --yolo permet de ne pas être interrompu, mais en contrepartie, il n’y a aucun filet de sécurité. Plus l’environnement peut être réinitialisé ou supprimé, plus ce mode est adapté. En revanche, dans les répertoires contenant de vrais identifiants ou des ressources en production, mieux vaut conserver une étape d’approbation ou le bac à sable.

Checklist pour utiliser Codex –yolo en toute sécurité

Comme les validations et le bac à sable sont désactivés, Codex peut faire tout ce que vous pourriez faire en tapant des commandes dans un terminal : supprimer des fichiers, modifier des configurations ou envoyer des requêtes réseau, sans être bloqué. Il vaut donc mieux prendre quelques précautions avant et après son utilisation :

En plus de ces conseils, gardez à l’esprit les points suivants :

1. Commencez par lancer codex --full-auto pour observer comment Codex travaille, puis décidez si vous souhaitez passer à --yolo.
2. Limitez l’usage de --yolo à un conteneur, une machine virtuelle ou un poste de développement dédié. Évitez de l’exécuter dans le répertoire personnel de votre ordinateur de travail habituel.
3. Créez un point de sauvegarde Git avant chaque tâche. À la fin, vérifiez les modifications avec git diff, puis décidez de les conserver ou de revenir en arrière.
4. Divisez les tâches en petites étapes. Plus une consigne est vague, plus l’IA risque d’entreprendre des actions inattendues sans supervision.

Comment utiliser Codex en ligne de commande avec Claude Code

Beaucoup de développeurs n’ont pas à choisir entre les deux : ils installent Codex et Claude Code sur la même machine. Leur approche de l’octroi de permissions est similaire, ce qui permet de transposer facilement ses habitudes d’un outil à l’autre :

• Développement au quotidien : utilisez Claude Code avec ses permissions par défaut et Codex avec codex ou codex --full-auto.
• Environnement isolé : utilisez Claude Code avec --dangerously-skip-permissions et Codex avec --yolo.
• Débogage collaboratif : demandez à un outil d’écrire le code et à l’autre de le vérifier. Avant de les lancer, assurez-vous que le dépôt Git est propre.

Si vous devez utiliser plusieurs modèles, comme ceux d’OpenAI, de Claude ou de Gemini, centraliser la gestion de vos clés avec APIYI (apiyi.com) vous simplifiera la tâche : une seule clé API et une interface compatible avec OpenAI pour tous les modèles. Vous pouvez ainsi passer de l’un à l’autre sans reconfigurer tout votre environnement. La facturation à l’usage facilite aussi le suivi des coûts réels.

FAQ : questions fréquentes

Points clés à retenir sur l’option --yolo de la CLI Codex

• Commande équivalente : dans Codex, l’équivalent de --dangerously-skip-permissions de Claude Code est codex --yolo.
• Forme complète : codex --dangerously-bypass-approvals-and-sandbox, qui produit le même effet que --yolo.
• Étendue des permissions : cette option ignore les demandes d’approbation et désactive le bac à sable. Elle ouvre donc davantage l’accès que son nom ne le laisse penser.
• Pour débuter : en développement local, commencez par codex --full-auto : le bac à sable reste actif, ce qui offre un bon équilibre entre efficacité et sécurité.
• Règle de sécurité : utilisez --yolo uniquement dans un environnement de confiance, réversible et jetable, et créez un commit Git au préalable.
• Accès aux modèles : avec APIYI apiyi.com et une seule clé, vous pouvez appeler plusieurs modèles populaires via https://api.apiyi.com/v1.

En résumé

Dans la CLI Codex, l’équivalent de claude --dangerously-skip-permissions est codex --yolo. La forme complète est codex --dangerously-bypass-approvals-and-sandbox. Pour vous y retrouver, retenez ces trois niveaux de permissions :

1. codex : permissions par défaut, avec approbations selon la configuration. Idéal pour les projets inconnus et les répertoires sensibles.
2. codex --full-auto : exécution automatique dans l’espace de travail, toujours limitée par le bac à sable. Idéal pour le développement local au quotidien.
3. codex --yolo : accès sans restrictions. À réserver aux environnements isolés et réversibles, auxquels vous faites confiance.

L’approche recommandée consiste à élargir les permissions progressivement : commencez par le mode par défaut pour vous familiariser avec le comportement de l’outil, passez ensuite à --full-auto pour gagner du temps, et ne recourez à --yolo qu’en cas de réel besoin. Pour tester rapidement l’accès aux modèles, APIYI apiyi.com propose un crédit d’essai gratuit et une interface unifiée pour plusieurs modèles.

Références

1. Documentation de configuration d’OpenAI Codex : guide officiel de configuration
2. Lien : developers.openai.com/docs/config-file/config-basic
3. Remarque : consultez la documentation pour connaître les dernières méthodes de configuration des paramètres de lancement, des règles d’approbation et du mode bac à sable. Les options disponibles dépendent de la version utilisée.

Auteur : équipe technique d’APIYI
Échanges techniques : contactez-nous depuis la page d’accueil du site d’APIYI. Pour en savoir plus, consultez le centre de documentation sur docs.apiyi.com.

Articles connexes

• Gemini 4 Argon vs Claude Opus 5.5 : décortiquons les 19 critères d’évaluation de Google pour déterminer, selon 4 dimensions, lequel est le plus performant.: À partir du tableau d’évaluation officiel de Google, comparez point par point Gemini 4 Argon et Claude Opus 5.5 sur 19 benchmarks couvrant le travail intellectuel, la programmation agentique, les longs contextes et le multimodal, en tenant compte des évaluations indépendantes d’Artificial Analysis et de Vals, des prix, des limites de sortie et de la disponibilité, afin de recommander le modèle adapté à chaque usage.
• Tutoriel pas à pas : une seule clé pour connecter tous les agents et unifier l’accès aux API avec la passerelle API open source magpie (exemples avec Claude Code, Codex, Pi et Hermes): Un tutoriel à suivre étape par étape : en environ 30 minutes, faites en sorte que tous les agents de programmation de votre machine (Claude Code, Codex, Pi et Hermes, par exemple) utilisent la même clé API et la même adresse de passerelle ; il comprend des captures d’écran de l’interface magpie, les étapes de configuration, une comparaison des configurations natives et un tableau de dépannage.
• Le Skill ultime utilisé par les développeurs des géants de la tech : tutoriel mattpocock/skills, avec 300 000 étoiles — 5 étapes pour démarrer : clarifiez d’abord vos besoins avec /grill-me, puis codez avec /tdd: Pour partir de zéro avec mattpocock/skills : installez-le via l’interface graphique, lancez /setup-matt-pocock-skills dans la boîte de dialogue, utilisez /grill-me pour clarifier les exigences de « validation des coupons », puis /tdd pour écrire le code avec un test à la fois ; l’article comprend un tableau de sélection des compétences et un tableau de dépannage.