Guides/Codex sollicite beaucoup le processeur

Codex sollicite beaucoup le processeur ou la mémoire sur un Mac ? Comment trouver la cause

Atta 🐬

Fondateur de Vitals

Publié le

Demander à l’IA ChatGPT Claude Perplexity AI Mode Grok Markdown

En bref

Codex existe en app de bureau et en outil en ligne de commande, et les deux lancent d’autres processus au fil de leur travail : les commandes qu’une tâche exécute, des serveurs de dev, des tests et des serveurs MCP. Un processeur très sollicité signifie en général qu’une tâche exécute quelque chose de lourd ou qu’une commande est bloquée ; une mémoire élevée, qu’un fil est ouvert depuis longtemps. Arrêtez la tâche, quittez complètement Codex puis rouvrez-le, et mettez-le à jour : vos fils sont conservés. Vitals, un moniteur système pour Mac, liste chaque processus qui travaille dans chaque dossier de projet et vous prévient quand l’un d’eux sollicite le processeur pendant plusieurs minutes.

Comment trouver ce que fait Codex

  1. 01 Ouvrez le Moniteur d’activité, cliquez sur Processeur et tapez codex dans le champ de recherche. L’app de bureau apparaît sous le nom Codex avec des processus utilitaires ; l’outil en ligne de commande apparaît comme codex sous votre app de terminal.
  2. 02 Choisissez Présentation → Toutes les opérations, hiérarchiquement, et ouvrez le triangle à côté de Codex ou de votre terminal. Ce qui se trouve en dessous est ce qu’une tâche a lancé : une compilation, des tests, un serveur de dev.
  3. 03 Si c’est l’un d’eux qui est occupé, arrêtez la tâche dans Codex. S’il continue de tourner après l’arrêt de la tâche, sélectionnez-le dans le Moniteur d’activité et cliquez sur le bouton Arrêter dans la barre d’outils.
  4. 04 Si c’est Codex lui-même qui est occupé ou volumineux, quittez-le avec ⌘Q et rouvrez-le. Dans le terminal, quittez et lancez codex resume pour reprendre le fil là où il s’était arrêté.
  5. 05 Mettez Codex à jour. L’app se met à jour depuis son propre menu ; l’outil en ligne de commande, avec le gestionnaire de paquets qui a servi à l’installer.

Si syspolicyd ou trustd est occupé en même temps que Codex, c’est macOS qui vérifie les programmes à leur lancement. Cela se calme tout seul quand la tâche cesse d’en lancer de nouveaux ; sinon, un redémarrage du Mac règle le problème.

Codex travaille en exécutant des choses : il lit votre projet, exécute des commandes dans un bac à sable, compile, teste et vérifie le résultat. C’est un vrai travail pour le processeur, et un Mac qui chauffe pendant qu’une tâche tourne fait ce qu’on lui a demandé. Les cas à régler sont autres : un processeur qui reste très sollicité une fois la tâche terminée, une mémoire qui grimpe tant qu’un fil reste ouvert, et des processus qui continuent après la fermeture de Codex. Le tableau fait le tri.

Où vont le processeur et la mémoire de Codex

Ce que vous voyezCe que c’estQue faire
Processeur très sollicité pendant qu’une tâche tourne La compilation, les tests ou le script que la tâche exécute Normal ; cela se termine avec la tâche
Processeur très sollicité sans tâche en cours Une commande qui ne s’est pas arrêtée, ou l’app bloquée Quittez ce que la tâche a lancé ; relancez Codex
Codex utilise de nombreux Go Un fil ouvert depuis longtemps Quittez et rouvrez ; vos fils sont conservés
syspolicyd ou trustd à un % processeur élevé macOS vérifie chaque programme qu’une tâche lance Se calme quand la tâche s’arrête ; sinon, redémarrez le Mac
Des processus qui restent après la fermeture de Codex Un serveur de dev, un outil de surveillance de fichiers ou un serveur MCP Quittez-les dans le Moniteur d’activité

Une tâche qui fait un vrai travail

Compiler un projet ou lancer une suite de tests utilise tous les cœurs disponibles, peu importe qui l’a demandé. Si Codex lance une compilation, ce sont les processus de la compilation, et non Codex, qui sont en haut du Moniteur d’activité, et les ventilateurs suivent. C’est le coût de la tâche. Faire tourner plusieurs tâches à la fois, chacune dans sa propre copie du projet, le multiplie : trois compilations en parallèle, ce sont trois compilations.

Quand cela ne s’arrête pas

Des utilisateurs signalent sur le suivi des bugs de Codex que l’app ou l’un de ses processus de travail occupe parfois un cœur en continu, ou grossit jusqu’à de nombreux gigaoctets, au cours d’une session ordinaire. Les solutions qui marchent sont les plus simples : arrêter la tâche, quitter Codex, le rouvrir, et le mettre à jour. Les fils sont enregistrés au fur et à mesure : relancer coûte quelques secondes, pas votre travail.

Vérifiez ce qui reste après avoir quitté. Un serveur de dev ou un outil de surveillance de fichiers lancé par une tâche est un processus ordinaire et ne se termine pas toujours avec elle. Triez le Moniteur d’activité par % processeur et par Mémoire, et cherchez node et d’autres outils de votre projet que vous n’avez pas lancés vous-même.

syspolicyd et trustd

macOS vérifie la signature d’un programme à son lancement. Une tâche qui lance des centaines de petits programmes en une minute, comme le font les compilations et les tests, occupe syspolicyd et trustd avec ces vérifications. Ils font partie de macOS et ne sont pas à quitter. Ils se calment quand les lancements s’arrêtent, et un redémarrage du Mac débloque une vérification restée coincée.

Ce que Vitals apporte

Vitals montre à quel projet appartient le travail, et vous prévient quand il dure trop longtemps.

  • Un onglet Projets : chaque processus qui travaille dans un dossier de projet, quelle que soit l’app qui l’a lancé, avec la mémoire, le processeur et l’énergie du projet dans son ensemble
  • Codex sur une seule ligne, utilitaires compris, avec sa mémoire et son processeur au total
  • Une notification quand une app sollicite le processeur pendant plusieurs minutes ou grossit sans cesse en mémoire
  • Les serveurs de dev restés lancés mais inactifs sont signalés, avec une proposition de les arrêter
  • Quand les ventilateurs tournent, les apps à l’origine de la chaleur, avec Quitter à côté de chacune

Bon à savoir

  • Vitals montre les processus et ce qu’ils utilisent. Il ne sait pas quelle tâche de Codex a lancé quelle commande.
  • Vitals ne quitte jamais rien de lui-même.
Obtenir Vitals pour $9 $9 pendant le lancement, $29 ensuite. Remboursement sous 14 jours.

Questions fréquentes

Pourquoi Codex sollicite-t-il autant le processeur de mon Mac ?

En général, parce qu’une tâche exécute une compilation, des tests ou un script, ce qui est un vrai travail. Si le processeur reste très sollicité sans tâche en cours, quittez ce que la tâche a lancé, relancez Codex et mettez-le à jour.

Pourquoi Codex utilise-t-il autant de mémoire ?

Un fil qui reste ouvert longtemps grossit. Quittez Codex et rouvrez-le ; les fils sont enregistrés, et codex resume en reprend un dans le terminal.

Pourquoi syspolicyd sollicite-t-il autant le processeur quand Codex tourne ?

macOS vérifie chaque programme à son lancement, et une tâche qui en lance beaucoup occupe syspolicyd. Cela se calme quand la tâche s’arrête. Ne le quittez pas ; redémarrez le Mac s’il reste bloqué.

Relancer Codex fait-il perdre mon travail ?

Non. Les fils et les modifications qu’une tâche a apportées à vos fichiers sont conservés. Rouvrez l’app, ou lancez codex resume dans le terminal.

Pourquoi mon Mac est-il chaud après que Codex a terminé ?

Quelque chose qu’une tâche a lancé tourne encore, le plus souvent un serveur de dev ou un outil de surveillance de fichiers. Triez le Moniteur d’activité par % processeur et quittez-le.

Existe-t-il une app qui montre ce que Codex fait tourner sur mon Mac ?

Vitals a un onglet Projets qui liste chaque processus qui travaille dans chaque dossier de projet, avec la mémoire, le processeur et les ports, et vous prévient quand l’un d’eux sollicite le processeur pendant plusieurs minutes.

Dans le lexique

Autres guides