Pourquoi le parcours e-mail nécessite une vérification humaine
Codex est l’agent de codage de OpenAI. Vous pouvez l’utiliser depuis le terminal, depuis votre éditeur, ou lui confier des tâches à traiter dans le cloud et relire le résultat. Il est bon pour le code autour de l’authentification : formulaires, routes API, gestion des jetons et modèles.
Mais une modification peut réussir tous les tests et quand même envoyer un e-mail qui pointe au mauvais endroit, qui n’arrive jamais parce que l’expéditeur n’est pas configuré, ou dont le code expire avant qu’on ait pu le saisir. Ces problèmes n’apparaissent que lorsqu’un vrai e-mail atteint une vraie boîte de réception.
Quelle connexion va-t-il créer ?
Celui que votre application utilise déjà, ou celui que vous demandez. Supabase Auth, Clerk, Firebase Authentication, Auth.js et Better Auth envoient chacun des e-mails différents, et chacun a un paramètre qui les casse le plus souvent. Nommez dans la tâche les méthodes voulues, par exemple « e-mail et mot de passe avec un code de confirmation, plus Google », pour que la modification et votre vérification couvrent les mêmes e-mails. Les e-mails envoyés par chaque service de connexion.
Vérifiez avant de fusionner
- Exécutez la branche. Lancez-la en local, ou ouvrez le déploiement de prévisualisation si votre hébergeur en crée un pour chaque modification.
- Créez une adresse dans Proxy Mail QA et inscrivez-vous, demandez un lien magique ou réinitialisez un mot de passe : selon ce que la modification a touché.
- Utilisez le code ou le lien de la ligne. Le code a un bouton Copier ; les liens deviennent un bouton nommé selon leur fonction.
- Lisez l’e-mail en entier une fois. Vérifiez l’expéditeur, l’objet, le texte et chaque lien dans la vue de la boîte de réception.
- Notez ce que vous avez trouvé sur l’adresse, pour que cela reste avec le compte de test.
Si le lien pointe vers localhost sur un déploiement de prévisualisation ou de staging, il est signalé. Cela indique généralement une URL codée en dur ou une variable d’environnement manquante : voir les correctifs.
Laissez Codex vérifier l’e-mail lui-même
Installez le plugin Proxy Mail QA depuis le répertoire de plugins de ChatGPT : il fonctionne dans Codex et dans ChatGPT. Connectez-vous à Proxy Mail QA dans votre navigateur quand il le demande et choisissez le projet qu’il peut utiliser, sans clé d’API à copier.
L’extension IDE Codex n’accepte pas les plugins. Pour y ajouter le MCP server, exécutez ceci dans un terminal :
codex mcp add proxymail-qa --url https://api.proxymail.qa/mcpCodex ouvre votre navigateur pour vous connecter ; sinon, exécutez codex mcp login proxymail-qa. La CLI Codex, l’extension IDE et l’application de bureau ChatGPT partagent ce paramètre. Pour utiliser plutôt une clé d’API, consultez Configuration de MCP server.
Demandez ensuite en langage courant : « Inscris-toi sur localhost:3000 avec une nouvelle adresse Proxy Mail QA et confirme l’e-mail. » Codex crée l’adresse, remplit votre formulaire, attend le code ou le lien et termine l’inscription. Il ne reçoit que le code ou le lien, jamais le texte de l’e-mail.
Transformez vos constats en tâche suivante
Donnez à Codex une consigne précise plutôt que « l’e-mail ne marche pas » :
- « Sur les déploiements de prévisualisation, le lien de vérification utilise
http://localhost:3000. Lis l’URL de base depuis une variable d’environnement. » - « L’e-mail du code indique 10 minutes, mais le serveur rejette les codes après 2. Aligne les deux. »
- « Demander un nouveau lien magique doit invalider le précédent. »
Conseils
- Une adresse par scénario. Créez-en un petit lot, chacune avec un nom et un nom d’utilisateur générés, pour les tests de nouvel utilisateur, d’utilisateur invité et de réinitialisation.
- Des étiquettes plus pour les exécutions répétées.
name+pr482@mailclub.devarrive dansname@mailclub.dev, avec l’étiquette affichée. - Enregistrez le mot de passe. Gardez le mot de passe de l’inscription sur la même ligne, chiffré et masqué jusqu’à ce que vous en ayez besoin.