Système de mémoire (Memories et Chronicle) : faire se souvenir de vous à travers les sessions

📚 Navigation dans la série : Le chapitre précédent [18 · Configuration détaillée du fichier config.toml] a expliqué comment régler l'ensemble des curseurs de comportement (modèle, bac à sable, approbations) dans un fichier unique. Ce chapitre aborde un sujet plus fondamental : comment permettre à Codex de se souvenir de vous d'une session à l'autre. Au-delà des consignes que vous rédigez dans AGENTS.md, il s'agit de la « note personnelle » que l'assistant accumule au cours de son travail — une correction que vous apportez une fois, qu'il mémorise en arrière-plan et réapplique automatiquement au démarrage suivant. Nous étudierons également Chronicle, une fonctionnalité expérimentale propre à Codex qui alimente la mémoire à partir des éléments affichés à l'écran.

Commençons par un court extrait d'une discussion réelle avec un collègue :

Mon collègue : « Tu m'avais dit que Codex gérait la mémoire ? Je viens de lui dire d'utiliser pnpm pour ce projet, et il s'est remis à faire des npm install immédiatement après. » Moi : « Tu as vérifié s'il avait eu le temps de l'enregistrer ? » Mon collègue : « Bah oui, l'interface n'a renvoyé aucune erreur. » Moi : « La mémoire ne s'écrit pas en temps réel. Elle est synthétisée en arrière-plan lorsque la session est inactive. Si tu le testes immédiatement après lui avoir parlé, c'est normal qu'il ne s'en souvienne pas. De plus, une règle stricte devant s'appliquer à chaque exécution doit être rédigée dans AGENTS.md, il ne faut pas s'en remettre uniquement à la mémoire. »

Cette discussion illustre les deux erreurs classiques concernant la mémoire de Codex : croire que la mémorisation est instantanée, et penser que la mémoire peut remplacer le fichier AGENTS.md. Ces deux hypothèses sont incorrectes et peuvent conduire à des erreurs d'exécution. Ce chapitre présente le fonctionnement de la mémoire de Codex : quand s'effectue la mémorisation, où sont stockés les souvenirs, comment les administrer et quelles données ne doivent jamais lui être confiées.

À la fin de ce chapitre, vous aurez en main :

• La distinction claire entre les deux systèmes de mémoire : le fichier rédigé par vos soins (AGENTS.md) et la mémoire automatique (Memories), avec un tableau comparatif.
• Le statut d'activation par défaut de la mémoire, les restrictions géographiques associées, sa configuration, son répertoire de stockage local et son mode de mise à jour asynchrone.
• L'utilisation de la commande /memories pour décider si une session doit exploiter les souvenirs existants et générer de nouveaux souvenirs, ainsi que les clés correspondantes dans config.toml.
• Une liste des éléments adaptés ou inadaptés à la mémoire, et la ligne rouge de sécurité à respecter.
• Le fonctionnement de Chronicle — l'outil expérimental propre à Codex qui capture les informations de l'écran pour alimenter la mémoire : ses possibilités, ses restrictions d'accès (réservé à macOS sous abonnement Pro, incompatible EEE/UK/Suisse) et ses implications de confidentialité.
• Un guide de configuration pratique pour activer et tester l'effet de la mémoire.

ℹ️ Comparaison avec le fonctionnement de Claude Code : Sur Claude Code, la mémorisation automatique est active par défaut, structurée par dépôt Git, et charge les premières lignes ou les premiers 25 Ko du fichier MEMORY.md. Le fonctionnement de Codex est différent : désactivé par défaut, soumis à des restrictions géographiques, généré en arrière-plan de manière asynchrone, et stocké dans des répertoires et configuré selon des paramètres distincts. Ces différences sont détaillées ci-dessous.

---

01 Distinguer les deux systèmes de mémoire

En résumé : Codex s'appuie sur deux systèmes de mémoire distincts : le fichier rédigé manuellement par vos soins (AGENTS.md) et les souvenirs générés automatiquement par l'assistant (Memories). Il est fréquent d'assimiler la mémoire à la seule fonction Memories, alors qu'elle ne représente qu'une partie du système de contexte, et pas nécessairement la plus fiable.

Analogie : Le plan de jeu de l'entraîneur et les notes personnelles du recruteur. L'entraîneur définit avant le match sur son tableau les consignes tactiques — le positionnement des joueurs, les marquages individuels et les phases arrêtées — que l'équipe doit appliquer strictement. C'est le rôle de AGENTS.md : des instructions claires, écrites, relues à chaque début de match (démarrage de tâche). Les notes du recruteur correspondent aux observations saisies sur son carnet depuis les tribunes — « la défense adverse est fragile sur le côté gauche » ou « l'attaquant a tendance à repiquer dans l'axe ». Ces notes ne lui sont pas imposées, il les accumule au fil de ses observations et les consulte lors d'une prochaine rencontre avec le même adversaire. C'est le rôle des Memories. Les deux approches sont complémentaires, mais l'une fixe des consignes obligatoires tandis que l'autre accumule des habitudes constatées.

La documentation officielle structure ainsi la répartition de ces deux outils :

Caractéristique	Fichier AGENTS.md	Mémoire automatique (Memories)
Auteur	L'utilisateur (rédaction manuelle)	Codex (synthèse automatique)
Contenu	Consignes et règles devant s'appliquer à chaque exécution	Contexte stable appris lors des sessions passées
Exemples d'usage	Commandes de compilation/test, règles de code, interdits	Technologies utilisées, habitudes du projet, enchaînements d'actions, résolutions de bugs
Statut par défaut	Actif (lu dès sa présence dans le projet)	Désactivé par défaut (activation manuelle requise)
Fiabilité	Déterministe (lu systématiquement à chaque démarrage)	Probabiliste (géré en arrière-plan, sans garantie de rappel)
Dépôt de code	Enregistré dans le dépôt Git (partagé avec l'équipe)	Stocké en local sur votre machine (exclu de Git)

Comprenons cette différence majeure : AGENTS.md regroupe les consignes à appliquer systématiquement, tandis que les Memories constituent un historique d'apprentissage local pour vous éviter de répéter vos habitudes de travail. La documentation officielle donne cette consigne :

Consignez les règles d'équipe devant s'appliquer systématiquement dans le fichier AGENTS.md ou dans la documentation du dépôt. Considérez la mémoire automatique comme une couche de rappel locale pratique, et non comme la source unique de vos règles absolues.

En clair : les Memories complètent le fonctionnement, mais ne garantissent pas l'application d'une règle critique. La consigne « n'utiliser que pnpm » mentionnée en introduction est une règle absolue qui doit figurer dans AGENTS.md pour être lue systématiquement, plutôt que d'être confiée à la mémoire automatique (qui peut ne pas l'avoir encore synthétisée ou ne pas la charger pour la session en cours). Le chapitre 11 présentait la rédaction de AGENTS.md ; ce chapitre est dédié à la gestion des souvenirs générés par l'assistant.

Visualisons comment ces deux flux alimentent le contexte d'une nouvelle session :

Ce schéma montre le fonctionnement : à gauche, le fichier AGENTS.md (rédigé par l'utilisateur, enregistré dans le projet et lu systématiquement à chaque tâche) ; à droite, les fichiers de Memories (gérés en local sous ~/.codex/memories/ et mis à jour de manière asynchrone par l'application). En bas, l'option expérimentale Chronicle capture des informations d'écran pour enrichir les Memories. Les deux sources fusionnent pour définir le contexte de la session active.

💡 En résumé : La mémoire de Codex repose sur deux approches : AGENTS.md (rédigé manuellement, déterministe, enregistré dans le projet Git) et les Memories (gérés en local par la machine, probabilistes, désactivés par défaut). Les règles impératives doivent être rédigées dans AGENTS.md.

---

02 La mémoire automatique (Memories) : Installation, fonctionnement et stockage

La mémoire automatique (Memories) permet à Codex d'accumuler ses propres notes au fil des sessions de travail. Elle évite d'avoir à décrire à chaque ouverture de session que vous développez en TypeScript, que vous omettez les points-virgules ou que les tests s'exécutent avec une commande spécifique. Une fois activée, elle charge ces habitudes de travail, conventions de code et résolutions de bugs antérieures dans les sessions suivantes.

Analogie : La complicité avec un collaborateur régulier. Un collaborateur débutant nécessite des instructions détaillées à chaque tâche. Un collaborateur avec qui vous travaillez depuis plusieurs années anticipe vos demandes car il connaît vos habitudes sans que vous ayez à les lui rappeler. La fonction Memories vise à faire évoluer Codex vers ce rôle de collaborateur régulier en analysant vos corrections pour identifier vos préférences.

Activation (désactivée par défaut)

C'est une différence majeure avec d'autres assistants :

La mémoire Memories est désactivée par défaut et n'est pas disponible pour les utilisateurs résidant dans l'Espace Économique Européen (EEE), au Royaume-Uni et en Suisse au lancement. Elle s'active dans les paramètres de l'application ou en déclarant memories = true sous le bloc [features] du fichier ~/.codex/config.toml.

Vous pouvez l'activer de deux manières :

Option A : Par le fichier de configuration (permanent, dans ~/.codex/config.toml) :

[features]
memories = true

Option B : Par l'interface graphique dans les paramètres de l'application Codex.

⚠️ La restriction géographique est appliquée au niveau du logiciel et non du réseau. Si vous résidez dans les zones EEE / Royaume-Uni / Suisse, la fonction ne sera pas disponible même avec l'usage d'un proxy.

Mécanisme d'écriture : Synthèse asynchrone en arrière-plan

C'est un comportement important à comprendre : la mémorisation n'est pas instantanée. La documentation décrit ce fonctionnement en trois points :

1. Analyse des sessions terminées : Codex extrait les informations des sessions passées significatives. Il ignore les sessions trop courtes ou en cours d'exécution pour éviter de mémoriser des données incomplètes. 2. Traitement différé lors de l'inactivity : La synthèse de la mémoire ne s'effectue pas dès la fermeture d'une session. Codex attend que l'application soit inactive pendant une durée suffisante pour lancer le traitement d'analyse en arrière-plan. Une question posée immédiatement après une correction ne pourra donc pas s'appuyer sur ce souvenir. 3. Préservation des limites de taux : Si votre crédit de requêtes API restant est inférieur à un certain seuil, le traitement de synthèse en arrière-plan est mis en pause pour réserver vos requêtes à votre travail de développement.

De plus, un filtre de sécurité tente de détecter et de masquer les clés API ou secrets présents dans les textes analysés avant de les écrire dans la mémoire. Toutefois, cette détection ne dispense pas de respecter les règles de sécurité relatives aux identifiants.

Emplacement de stockage local

Les données de mémoire sont stockées en local sur votre machine dans le répertoire suivant :

Le dossier de stockage se situe au sein de votre répertoire principal Codex (CODEX_HOME, par défaut ~/.codex/memories/). Les fichiers générés (dont les noms sont gérés par l'application) se répartissent ainsi :

~/.codex/memories/
├── (fichiers de synthèse)
├── (fichiers de règles persistantes)
├── (historique des saisies récentes)
└── (références de sessions passées)

La documentation officielle précise l'usage de ces fichiers :

Ces fichiers décrivent l'état de la mémoire généré par Codex. Vous pouvez les consulter pour diagnostic ou avant de partager votre répertoire global, mais évitez de les éditer manuellement. La gestion de la mémoire doit se faire via les commandes et paramètres de configuration.

Pour modifier le comportement de la mémoire, utilisez la commande /memories ou les clés de configuration dédiées plutôt que d'éditer directement les fichiers Markdown générés.

Caractéristique	Fichier AGENTS.md	Mémoire automatique (Memories)
Statut par défaut	Actif dès sa détection	Désactivé par défaut, activation manuelle requise
Moment d'écriture	Immédiat à la sauvegarde du fichier	Différé, en arrière-plan après inactivité de la session
Stockage	Dans le répertoire du projet (suivi par Git)	Dans ~/.codex/memories/ (exclus de Git)
Modification	Édition directe recommandée	Pilotage par /memories et config.toml

💡 En résumé : Les Memories sont des notes locales générées par Codex, stockées dans ~/.codex/memories/ et désactivées par défaut (memories = true requis). Le traitement s'effectue en arrière-plan après une période d'inactivité de la session, et non en temps réel.

---

03 Gestion des souvenirs : La commande /memories et les paramètres de configuration

Une fois la mémoire active, vous devez pouvoir contrôler son comportement : déterminer si une session spécifique doit exploiter les souvenirs existants ou si elle doit alimenter l'apprentissage futur. Vous pouvez par exemple souhaiter désactiver la mémorisation lors de tests sur des codes éphémères ou lors de manipulations de données confidentielles. Codex propose un contrôle au niveau de la session et un contrôle global.

Analogie : Les touches d'enregistrement et de lecture d'un dictaphone. La touche de lecture détermine si vous souhaitez écouter les enregistrements passés (exploiter les souvenirs existants), tandis que la touche d'enregistrement décide si vous souhaitez enregistrer la discussion en cours (alimenter la mémoire). Ces deux actions sont indépendantes : vous pouvez écouter sans enregistrer, enregistrer sans écouter ou couper les deux fonctions. La commande /memories offre ce niveau de contrôle.

Session active : La commande /memories

Saisissez /memories dans le chat de l'application ou du terminal (TUI) pour configurer la session en cours :

/memories

Un menu s'affiche pour vous permettre de définir si la session doit charger les souvenirs existants, participer à la synthèse de la mémoire future, ou désactiver totalement le comportement de mémoire. Ces choix s'appliquent exclusivement à la session en cours et n'altèrent pas vos paramètres par défaut globaux.

Conseil pratique : laissez la mémoire active pour vos développements classiques, et désactivez la mémorisation (via /memories) lorsque vous effectuez des tests rapides ou manipulez des données sensibles pour éviter d'enregistrer des informations temporaires ou confidentielles dans vos fichiers de mémoire à long terme.

Paramètres globaux dans le fichier config.toml

Pour modifier le comportement par défaut de la mémoire de manière permanente, éditez la section [memories] de votre fichier ~/.codex/config.toml :

Les valeurs par défaut listées ci-dessous correspondent aux spécifications de l'éditeur et peuvent évoluer selon les versions.

Clé de configuration	Rôle	Valeur par défaut
memories.use_memories	Permet d'injecter les souvenirs existants dans les nouvelles sessions	true
memories.generate_memories	Permet d'analyser les sessions pour enrichir la mémoire	true
memories.disable_on_external_context	Désactive la mémorisation pour les sessions ayant exploité des contextes externes (MCP, recherche web)	false
memories.min_rate_limit_remaining_percent	Seuil de crédit de requêtes restant sous lequel la synthèse est suspendue	25
memories.extract_model	Modèle spécifique à utiliser pour l'extraction des souvenirs	Géré par l'application
memories.consolidation_model	Modèle spécifique à utiliser pour la fusion et le nettoyage de la mémoire	Géré par l'application

Exemple pour exploiter les souvenirs existants tout en bloquant l'apprentissage de nouvelles habitudes :

[memories]
generate_memories = false
use_memories = true

Note technique : La clé memories.disable_on_external_context possédait l'ancienne dénomination memories.no_memories_if_mcp_or_web_search, qui reste acceptée pour compatibilité. Le rôle de ce paramètre (détaillé au chapitre 20 sur les MCP) est d'exclure de l'apprentissage les sessions ayant manipulé des outils externes afin de préserver la propreté du contexte mémorisé.

💡 En résumé : Utilisez la commande /memories pour modifier le comportement de la session active sans impacter les paramètres globaux. Utilisez les clés use_memories et generate_memories sous la section [memories] du fichier config.toml pour définir les règles par défaut de l'application.

---

04 Choisir les informations à mémoriser et précautions de sécurité

Bien que Codex cible les informations stables d'une session à l'autre, vous devez identifier ce qu'il convient de confier à la mémoire Memories et ce qui doit en être exclu.

Voici une synthèse des usages adaptés pour chacun des deux systèmes :

❌ À exclure de la mémoire (utiliser AGENTS.md ou désactiver)	✅ Adapté à la mémoire automatique (Memories)
Règle absolue du projet (« utiliser pnpm et bannir npm ») → à inscrire dans AGENTS.md	Technologies et frameworks couramment utilisés (TypeScript, PostgreSQL)
Paramètre temporaire (« utiliser le port 8081 pour ce test »)	Habitudes de validation (lancer un linter avant de commiter)
Informations liées à la tâche en cours (« développement de la page de login »)	Conventions du dépôt (les tests requièrent un service local actif)
Fichiers de clés, mots de passe, secrets de cloud → sécurité (ligne rouge)	Résolutions d'erreurs (le bug de fuseau horaire a été corrigé ainsi)

Règles de décision :

1. Impératifs vs Habitudes : Les règles absolues devant s'appliquer à chaque tâche doivent être documentées dans AGENTS.md pour être lues systématiquement. La mémoire automatique (Memories) est probabiliste et peut ne pas charger l'information lors d'une session. Ne lui confiez pas de règles critiques. 2. Pérennité des informations : Excluez les paramètres temporaires ou les états de développement immédiats qui pollueraient la mémoire future avec des données obsolètes. 3. Préservation des secrets (Ligne rouge) :

Ne stockez jamais d'identifiants ou de secrets dans la mémoire. Bien que Codex intègre un filtre de masquage, les fichiers de mémoire sont écrits en clair sur votre disque. Vous devez vérifier leur contenu avant de partager votre répertoire global.

Les données de mémoire étant stockées sous forme de fichiers Markdown non chiffrés sur votre disque local, la prudence impose d'exclure les clés API ou mots de passe de vos sessions actives. Prenez l'habitude de vérifier le contenu du dossier ~/.codex/memories/ avant de partager ou de sauvegarder votre répertoire de configuration.

💡 En résumé : Les consignes impératives doivent être écrites dans AGENTS.md, et les secrets ou clés API doivent être exclus des sessions pour ne pas être mémorisés. Les Memories sont adaptées pour stocker les préférences de langages, de frameworks ou les résolutions de bugs récurrents.

---

05 La fonctionnalité Chronicle (alimentation par analyse de l'écran)

Codex propose une fonctionnalité expérimentale d'enrichissement de la mémoire appelée Chronicle, qui n'a pas d'équivalent dans Claude Code.

⚠️ Fonctionnalité expérimentale en cours d'évaluation (research preview) sujette à modification. Fiez-vous aux indications de votre interface et à la documentation officielle de votre version.

Rôle et fonctionnement

Alors que la mémoire Memories classique s'appuie sur le texte de vos discussions avec l'assistant, Chronicle analyse les éléments affichés à l'écran de votre ordinateur pour enrichir le contexte et aider l'assistant à identifier vos outils de travail et vos documents de référence.

Analogie : Un assistant qui observe vos manipulations. Un assistant classique écoute uniquement vos descriptions orales. Un assistant équipé de Chronicle analyse du coin de l'œil ce qui s'affiche à l'écran — « vous étudiez ce message d'erreur » ou « vous modifiez ce fichier de configuration » — pour anticiper vos besoins sans description préalable. La documentation indique que Chronicle utilise ces indices visuels pour identifier les fichiers de code, tickets ou documentations concernés par votre tâche et les charger au besoin.

Restrictions de plateforme et de droits

L'accès à Chronicle est soumis à des critères stricts :

• Abonnement : Réservé aux comptes ChatGPT Pro.
• Plateforme : Disponible uniquement sous macOS (incompatible avec Windows et Linux).
• Localisation : Non disponible pour les utilisateurs résidant dans la zone EEE, au Royaume-Uni et en Suisse.

L'activation requiert les droits système Enregistrement de l'écran (Screen Recording) et Accessibilité (Accessibility) sous macOS. Le chemin d'accès se situe dans les paramètres de Codex : onglet Personalization → s'assurer que Memories est actif → activer Chronicle et valider les demandes de permissions d'accès système.

Implications de confidentialité et précautions d'usage

La documentation officielle détaille trois points d'attention importants avant d'activer Chronicle :

1. Consommation de ressources : L'analyse en arrière-plan s'appuie sur des agents de capture d'écran qui consomment rapidement votre crédit de requêtes d'exécution.
2. Exposition aux injections de requêtes : Lire des textes affichés à l'écran augmente le risque d'injection de requêtes (prompt injection) si vous affichez des sites web tiers contenant des instructions cachées destinées à l'IA.
3. Stockage en clair : Les synthèses d'écran générées par Chronicle sont stockées localement sous forme de fichiers Markdown non chiffrés.

Vous pouvez suspendre l'activité de Chronicle à tout moment depuis la barre des menus de macOS en sélectionnant Pause Chronicle (et la relancer avec Resume Chronicle). Suspendez systématiquement Chronicle lors de réunions en ligne, de saisies d'identifiants ou de manipulation de données confidentielles. De plus, respectez le consentement de vos collaborateurs en évitant d'activer la capture d'écran lors d'échanges collaboratifs.

Gestion des données

• Captures d'écran temporaires : Les images d'écran sont stockées temporairement en local sous $TMPDIR/chronicle/screen_recording/ et sont supprimées automatiquement après 6 heures.
• Synthèses de mémoire locales : Les synthèses extraites sont écrites dans $CODEX_HOME/memories_extensions/chronicle/ (généralement ~/.codex/memories_extensions/chronicle). Vous pouvez éditer ou supprimer ces fichiers Markdown pour retirer des souvenirs, mais évitez d'y ajouter manuellement du contenu.
• Traitement des images : Les captures d'écran transmises à OpenAI pour analyse textuelle (OCR et reconnaissance d'éléments) sont supprimées des serveurs après traitement et ne sont pas conservées pour l'entraînement des modèles.

💡 En résumé : Chronicle enrichit la mémoire en analysant l'écran sous macOS pour les abonnés ChatGPT Pro hors zone EEE/UK/Suisse. Son usage exige de la vigilance concernant la confidentialité (possibilité de suspendre via le menu système) et le stockage en clair des données de synthèse locales.

---

06 En pratique : Activer, alimenter et vérifier la mémoire

Voici un exercice pour activer la mémoire, lui transmettre une préférence et vérifier la création du fichier de stockage.

Note technique : Les commandes de création de dossiers s'exécutent en console sous macOS/Linux ou dans Git Bash sous Windows. La mémoire n'étant pas disponible en zone EEE/UK/Suisse, l'exercice ne fonctionnera pas dans ces régions.

Étape 1 : Activer la mémoire

Dans votre fichier de configuration utilisateur ~/.codex/config.toml, ajoutez ces lignes :

[features]
memories = true

Vous pouvez également l'activer dans les paramètres graphiques de Codex.

Étape 2 : Créer un dossier de test et lancer Codex

mkdir memory-demo
cd memory-demo
codex

La session s'ouvre.

Étape 3 : Saisir une préférence de travail

Indiquez une habitude de codage stable dans le chat :

Pour ce projet, les tests s'exécutent avec pytest. Mémorise cette habitude.

Codex valide la demande. Notez que l'information n'est pas encore écrite dans les fichiers de stockage globaux, le traitement de synthèse s'effectuant en arrière-plan après une période d'inactivité de la session.

Étape 4 : Utiliser le contrôle de session /memories

Saisissez la commande suivante dans le chat :

/memories

Le menu s'affiche pour vous permettre de modifier la prise en compte de la mémoire pour la session active sans impacter vos règles globales (par exemple pour désactiver l'apprentissage de cette session).

Étape 5 : Vérifier le répertoire de stockage local

Après avoir laissé la session inactive ou après fermeture, listez le contenu du dossier de stockage dans votre console :

ls ~/.codex/memories/

Comportement attendu : Des fichiers Markdown (synthèses et références) doivent apparaître dans ce dossier, confirmant la prise en compte de la mémoire automatique. En cas d'absence de fichier, vérifiez l'activation de l'option dans config.toml, la zone géographique d'utilisation et le niveau de crédit de requêtes API restant sur votre compte.

💡 En résumé : L'exercice consiste à activer la clé dans la configuration, transmettre une consigne, manipuler les options de session avec /memories et constater la création des fichiers Markdown dans ~/.codex/memories/ après traitement asynchrone.

---

07 Résumé

Ce chapitre a détaillé le fonctionnement des deux systèmes de mémorisation de Codex pour vous aider à conserver le contexte de vos sessions.

Voici les points clés à retenir :

Aspect	Fichier AGENTS.md	Mémoire automatique (Memories)
Rôle	Règle absolue et déterministe	Contexte d'apprentissage probabiliste
Configuration	Écrit manuellement dans le projet Git	Activé via memories = true ou les paramètres graphiques
Écriture	Immédiate à la sauvegarde	Différée, en arrière-plan lors de l'inactivité
Limites	Aucune restriction	Non disponible en zone EEE/UK/Suisse
Contrôle	Édition du fichier Markdown	Commande /memories en session et table [memories] dans config.toml
Chronicle	Non applicable	Option expérimentale d'analyse d'écran sous macOS (Pro)

Vous êtes désormais en mesure de répartir vos consignes entre le fichier déterministe AGENTS.md et les Memories, d'activer la mémoire Memories, d'identifier les conditions d'écriture du traitement asynchrone, d'administrer les souvenirs avec la commande /memories, d'exclure les secrets de la mémoire locale, et de comprendre les apports et exigences de la fonction Chronicle.

---

Le chapitre suivant 20 · Connecter des outils via le protocole Model Context Protocol (MCP) présente l'intégration d'outils externes : qu'est-ce que le protocole MCP, comment configurer un serveur MCP pour donner à Codex l'accès à vos bases de données ou à des API tierces, et comment sécuriser ces accès ? Nous verrons comment étendre les capacités d'action de notre assistant.

---

Lectures recommandées

• Rédiger des invites (prompts) efficaces pour Codex
• Exercice de synthèse : créer et tester une application avec Codex
• Prise en main de l'interface en ligne de commande CLI