Avec Design Mode dans le navigateur Cursor, vous pouvez cliquer, dessiner ou décrire oralement des modifications pour aider les agents à mettre à jour votre interface.
Cliquez sur au moins deux éléments à la fois dans le navigateur. Cursor voit les éléments sélectionnés, leur code, la disposition autour d’eux et les relations visuelles sur la page.
Demandez à l’agent de faire correspondre l’un à l’autre, de supprimer le contenu en double ou d’ajuster un groupe de composants à la fois.
Décrivez les modifications dans la surcouche Design Mode. Le micro reste disponible pendant qu’un agent s’exécute, vous pouvez donc mettre la modification suivante en attente par la voix sans attendre que la précédente soit terminée.
Nous avons livré un lot de nouvelles fonctionnalités pour les SDK TypeScript et Python. Vous pouvez désormais choisir comment les métadonnées des agents et des exécutions sont conservées, exposer vos propres fonctions à l'agent sous forme d'outils, faire passer les appels d'outils locaux par la revue automatique, et imbriquer des sous-agents sur autant de niveaux que nécessaire. Cette version apporte également un ensemble de correctifs de fiabilité, de performances et de plateforme qui facilitent l'exécution des agents SDK locaux et cloud dans des scripts de production, en CI et dans des intégrations personnalisées.
Vous pouvez désormais transmettre à l’agent local vos propres outils en passant des définitions de fonctions via local.customTools, dans Agent.create() ou pour chaque send(). Le SDK les expose à l’agent via un serveur MCP intégré appelé custom-user-tools, afin que le modèle appelle votre code par le même chemin et avec le même contrôle d’autorisation que n’importe quel autre outil MCP.
Auparavant, exposer une fonctionnalité personnalisée impliquait de mettre en place votre propre serveur MCP stdio ou HTTP distant et de le raccorder à l’agent. Désormais, une définition de fonction suffit. Les outils personnalisés sont également visibles par tous les sous-agents d’un agent parent ; ainsi, un outil défini une seule fois reste disponible tout au long de l’exécution.
Par défaut, un agent SDK local exécute les appels d’outil sans demander d’approbation, puisqu’il n’y a pas d’humain dans la boucle lors d’une exécution en mode headless. Définissez local.autoReview pour faire passer ces appels par la revue automatique à la place. Un classificateur décide quels appels s’exécutent automatiquement et lesquels doivent être mis en attente, plutôt que de contourner entièrement la revue.
Vous guidez ce classificateur à l’aide d’instructions en langage naturel dans permissions.json. Le champ autoRun.allow_instructions décrit les types d’appels à privilégier, et autoRun.block_instructions décrit ceux à mettre en attente pour revue. Par exemple, vous pouvez autoriser des inspections en lecture seule des artefacts de build, tout en mettant systématiquement en pause les opérations destructrices comme les suppressions.
{ "autoRun": { "allow_instructions": [ "Read-only inspections of build artifacts under ./dist are fine." ], "block_instructions": [ "Always pause delete operations so I get a chance to review them." ] }}
Les deux SDK conservent les métadonnées des agents et des exécutions afin que vous puissiez reprendre un agent après le redémarrage d’un processus. Jusqu’à présent, ce stockage reposait sur SQLite. Vous pouvez désormais choisir d’utiliser à la place un stockage JSONL, qui écrit dans un simple fichier en ajout seul, que vous pouvez lire, comparer et enregistrer dans votre système de gestion de versions. SqliteLocalAgentStore et JsonlLocalAgentStore sont tous deux exportés directement.
Si aucune de ces options par défaut ne convient à votre configuration, implémentez l’interface publique LocalAgentStore et transmettez-la via local.store. Créez un stockage en mémoire pour des exécutions CI éphémères, ou utilisez Postgres comme backend de persistance lorsque vous souhaitez que l’état de l’agent soit stocké avec le reste des données de votre application. Le SDK Python expose des stockages hôte, JSONL et JSONL composés via le bridge.
Les sous-agents peuvent désormais lancer leurs propres sous-agents, et ainsi de suite. Un sous-agent chargé de la revue peut déléguer à un sous-agent chargé d’écrire les tests, qui peut à son tour déléguer davantage, chaque niveau conservant son propre prompt et son propre modèle. Il n’y a rien à activer : une session de sous-agent enregistre l’exécuteur dont elle a besoin pour appeler Task, donc l’imbrication fonctionne automatiquement pour tout agent qui définit des sous-agents.
#Fiabilité, performances et améliorations de la plateforme
Cette version inclut également une série de correctifs de qualité de vie dans les deux SDK.
Corrélation des exécutions : chaque send() inclut désormais un requestId généré par la plateforme, exposé dans Run et RunResult et conservé dans les stockages en mémoire, SQLite et JSONL. Reliez un script ou une exécution CI aux journaux du backend, aux analyses et aux échanges avec le support sans avoir à l’inférer à partir de agentId.
wait() fiable sur les exécutions locales : les exécutions locales ne résolvent plus wait() avant l’écriture du résultat terminal. L’hydratation continue de se rafraîchir jusqu’à ce que l’exécution atteigne un état final, afin que l’automatisation lise un résultat complet.
Checkpoints sûrs lors de la libération : la libération d’un agent local ne supprime plus les données de checkpoint lorsqu’une référence racine est absente mais que des blobs de checkpoint existent encore. Le répertoire de l’agent n’est vidé que lorsqu’il ne reste réellement plus rien à conserver.
Streaming Cloud via HTTP/1.1 : les sessions d’agent Cloud diffusent désormais correctement sur les transports HTTP/1.1 utilisés par certains proxys, d’anciennes implémentations fetch de Node et certaines images CI. Le comportement en HTTP/2 reste inchangé.
Import plus léger : importer @cursor/sdk ne charge plus d’emblée l’intégralité de la stack d’agents locale. Les usages Cloud uniquement et de types uniquement évitent le coût du runtime local jusqu’au premier appel local, sans changement d’API. Le premier appel local entraîne un import unique, ensuite mis en cache.
Types TypeScript autonomes : les fichiers .d.ts publiés ne référencent plus de packages de workspace non publiés. Cela corrige les erreurs TS2305 et TS2307 avec skipLibCheck: false, ainsi que les any silencieux sur les types de flux comme TurnEndedUpdate.
ripgrep intégré : les exécutions shell locales utilisent le binaire rg intégré à la plateforme sans modifier votre PATH global. Sous Windows, le préfixage de ripgrep n’écrase plus la variable Path.
Composer 2 est redirigé vers Composer 2.5 : les clients SDK qui pointent encore vers les slugs composer-2 retirés sont automatiquement redirigés vers Composer 2.5, tout en conservant les variantes rapides, afin que les anciens scripts continuent de s’exécuter.
list_runs limité au workspace : Client, AsyncClient et Agent.list_runs acceptent un cwd facultatif, et le bridge revient par défaut au workspace de lancement. Cela corrige les résultats « agent introuvable » intempestifs lorsque le bridge s’exécute comme sous-processus.
Erreurs d’absence plus claires : rechercher un agent qui n’est pas dans le workspace résolu renvoie une erreur explicite indiquant qu’il est introuvable, au lieu d’une erreur interne opaque.
Version 0.1.6 et analyses : cursor-sdk 0.1.6 documente le circuit de publication Buildkite et étiquette l’utilisation du SDK comme sdk-python- pour des analyses plus claires.
Exécutez npm install @cursor/sdk ou pip install cursor-sdk pour mettre à niveau. Les scripts qui pointent vers composer-2 passent automatiquement à Composer 2.5, et requestId est un ajout sûr à votre schéma de métadonnées d’exécution. Consultez la documentation TypeScript et Python pour tous les détails.
Avec les canevas, les agents peuvent créer des artefacts interactifs, comme des tableaux de bord, des rapports et des outils internes, que vous pouvez partager avec votre équipe.
Cette version introduit le mode Design pour modifier les canevas plus rapidement, de nouvelles façons de comprendre l’utilisation du contexte, ainsi que d’autres améliorations pratiques.
Le mode Design est désormais disponible dans les canevas.
Sélectionnez et annotez directement des éléments de l’interface dans un canevas pour guider les modifications de Cursor, comme vous le feriez dans le navigateur. Au lieu de décrire la modification par écrit, vous pouvez simplement la pointer, donner votre avis et itérer plus rapidement.
#Rapport d’utilisation du contexte dans un canevas
Cursor peut désormais afficher l’utilisation du contexte de votre agent sous la forme d’un rapport interactif dans un canevas.
L’explorateur de contexte détaille la répartition des tokens entre le prompt système, les définitions d’outils, les règles, les skills, et bien plus encore. Comme il s’agit d’un canevas, vous pouvez poser des questions de suivi à l’agent, qui peut personnaliser le rapport pour répondre à vos questions spécifiques.
Cliquez sur le bouton Debug with Agent intégré au canevas pour demander à Cursor d’identifier des pistes pour réduire l’utilisation du contexte dans une nouvelle conversation.
Les canevas partagés peuvent désormais être ouverts en plein écran dans le Browser, ce qui facilite leur présentation à d’autres personnes.
Ajout de la possibilité pour les agents d’intégrer dans les canevas des boutons qui exécuteront un prompt spécifique lorsqu’on clique dessus.
Amélioration de la capacité de l’agent à corriger les erreurs de type dans les canevas.
Amélioration du style des composants et ajout de fonctionnalités supplémentaires de personnalisation des graphiques.
Les clients Enterprise peuvent désormais gérer plusieurs Teams Cursor depuis un seul endroit, avec des contrôles distincts en matière de sécurité, de gouvernance, de budget et de fonctionnalités pour chacune. Ces capacités sont désormais disponibles pour tous les clients Enterprise.
Une organisation est le conteneur principal de l’identité, de l’administration et des membres de votre entreprise. Elle offre aux administrateurs un point central pour consulter et gérer l’ensemble de leur installation Cursor, y compris une vue agrégée des dépenses et de l’utilisation des tokens de toutes les équipes.
Les équipes constituent l’unité opérationnelle d’un département, d’une région ou d’une filiale. C’est ce que les administrateurs gèrent aujourd’hui comme organisation Cursor. Nous avons rattaché cette unité à une organisation, afin que vous puissiez gérer plusieurs équipes, chacune avec ses propres paramètres de sécurité, de gouvernance, de dépense et de fonctionnalités.
Un utilisateur peut appartenir à plusieurs équipes, avec un rôle différent dans chacune. Pour les clients actuels, votre équipe existante est conservée et devient le point d’entrée par défaut pour la connexion, le routage et la création de nouvelles équipes.
Les groupes sont une collection légère d’utilisateurs pouvant s’étendre à plusieurs Teams ou exister au sein d’une même Team. Ils permettent d’attribuer à des cohortes d’utilisateurs un accès distinct aux modèles, des plafonds de dépenses et des permissions des agents, sans devoir créer une toute nouvelle Team. Lorsqu’un utilisateur appartient à plusieurs Teams ou groupes, le paramètre le plus permissif prévaut.
Auto-review est un nouveau mode d’exécution qui permet à Cursor de fonctionner plus longtemps, avec moins de demandes d’approbation et une exécution plus sûre.
Auto-review s’applique aux appels d’outil Shell, MCP et Fetch. Les appels figurant sur la liste d’autorisation s’exécutent immédiatement, et ceux qui peuvent être sandboxés s’exécutent dans le sandbox. Toutes les autres actions de l’agent sont envoyées à un sous-agent classifieur qui décide s’il faut autoriser l’appel, essayer une autre approche ou demander votre approbation.
Configurez votre mode d’exécution dans Settings > Cursor Settings > Agents > Run Mode. Vous pouvez également orienter l’agent classifieur en lui donnant des instructions personnalisées.
Avec Design Mode dans le navigateur Cursor, vous pouvez cliquer, dessiner ou décrire oralement des modifications pour aider les agents à mettre à jour votre interface.
Cliquez sur au moins deux éléments à la fois dans le navigateur. Cursor voit les éléments sélectionnés, leur code, la disposition autour d’eux et les relations visuelles sur la page.
Demandez à l’agent de faire correspondre l’un à l’autre, de supprimer le contenu en double ou d’ajuster un groupe de composants à la fois.
Décrivez les modifications dans la surcouche Design Mode. Le micro reste disponible pendant qu’un agent s’exécute, vous pouvez donc mettre la modification suivante en attente par la voix sans attendre que la précédente soit terminée.
Nous avons livré un lot de nouvelles fonctionnalités pour les SDK TypeScript et Python. Vous pouvez désormais choisir comment les métadonnées des agents et des exécutions sont conservées, exposer vos propres fonctions à l'agent sous forme d'outils, faire passer les appels d'outils locaux par la revue automatique, et imbriquer des sous-agents sur autant de niveaux que nécessaire. Cette version apporte également un ensemble de correctifs de fiabilité, de performances et de plateforme qui facilitent l'exécution des agents SDK locaux et cloud dans des scripts de production, en CI et dans des intégrations personnalisées.
Vous pouvez désormais transmettre à l’agent local vos propres outils en passant des définitions de fonctions via local.customTools, dans Agent.create() ou pour chaque send(). Le SDK les expose à l’agent via un serveur MCP intégré appelé custom-user-tools, afin que le modèle appelle votre code par le même chemin et avec le même contrôle d’autorisation que n’importe quel autre outil MCP.
Auparavant, exposer une fonctionnalité personnalisée impliquait de mettre en place votre propre serveur MCP stdio ou HTTP distant et de le raccorder à l’agent. Désormais, une définition de fonction suffit. Les outils personnalisés sont également visibles par tous les sous-agents d’un agent parent ; ainsi, un outil défini une seule fois reste disponible tout au long de l’exécution.
Par défaut, un agent SDK local exécute les appels d’outil sans demander d’approbation, puisqu’il n’y a pas d’humain dans la boucle lors d’une exécution en mode headless. Définissez local.autoReview pour faire passer ces appels par la revue automatique à la place. Un classificateur décide quels appels s’exécutent automatiquement et lesquels doivent être mis en attente, plutôt que de contourner entièrement la revue.
Vous guidez ce classificateur à l’aide d’instructions en langage naturel dans permissions.json. Le champ autoRun.allow_instructions décrit les types d’appels à privilégier, et autoRun.block_instructions décrit ceux à mettre en attente pour revue. Par exemple, vous pouvez autoriser des inspections en lecture seule des artefacts de build, tout en mettant systématiquement en pause les opérations destructrices comme les suppressions.
{ "autoRun": { "allow_instructions": [ "Read-only inspections of build artifacts under ./dist are fine." ], "block_instructions": [ "Always pause delete operations so I get a chance to review them." ] }}
Les deux SDK conservent les métadonnées des agents et des exécutions afin que vous puissiez reprendre un agent après le redémarrage d’un processus. Jusqu’à présent, ce stockage reposait sur SQLite. Vous pouvez désormais choisir d’utiliser à la place un stockage JSONL, qui écrit dans un simple fichier en ajout seul, que vous pouvez lire, comparer et enregistrer dans votre système de gestion de versions. SqliteLocalAgentStore et JsonlLocalAgentStore sont tous deux exportés directement.
Si aucune de ces options par défaut ne convient à votre configuration, implémentez l’interface publique LocalAgentStore et transmettez-la via local.store. Créez un stockage en mémoire pour des exécutions CI éphémères, ou utilisez Postgres comme backend de persistance lorsque vous souhaitez que l’état de l’agent soit stocké avec le reste des données de votre application. Le SDK Python expose des stockages hôte, JSONL et JSONL composés via le bridge.
Les sous-agents peuvent désormais lancer leurs propres sous-agents, et ainsi de suite. Un sous-agent chargé de la revue peut déléguer à un sous-agent chargé d’écrire les tests, qui peut à son tour déléguer davantage, chaque niveau conservant son propre prompt et son propre modèle. Il n’y a rien à activer : une session de sous-agent enregistre l’exécuteur dont elle a besoin pour appeler Task, donc l’imbrication fonctionne automatiquement pour tout agent qui définit des sous-agents.
#Fiabilité, performances et améliorations de la plateforme
Cette version inclut également une série de correctifs de qualité de vie dans les deux SDK.
Corrélation des exécutions : chaque send() inclut désormais un requestId généré par la plateforme, exposé dans Run et RunResult et conservé dans les stockages en mémoire, SQLite et JSONL. Reliez un script ou une exécution CI aux journaux du backend, aux analyses et aux échanges avec le support sans avoir à l’inférer à partir de agentId.
wait() fiable sur les exécutions locales : les exécutions locales ne résolvent plus wait() avant l’écriture du résultat terminal. L’hydratation continue de se rafraîchir jusqu’à ce que l’exécution atteigne un état final, afin que l’automatisation lise un résultat complet.
Checkpoints sûrs lors de la libération : la libération d’un agent local ne supprime plus les données de checkpoint lorsqu’une référence racine est absente mais que des blobs de checkpoint existent encore. Le répertoire de l’agent n’est vidé que lorsqu’il ne reste réellement plus rien à conserver.
Streaming Cloud via HTTP/1.1 : les sessions d’agent Cloud diffusent désormais correctement sur les transports HTTP/1.1 utilisés par certains proxys, d’anciennes implémentations fetch de Node et certaines images CI. Le comportement en HTTP/2 reste inchangé.
Import plus léger : importer @cursor/sdk ne charge plus d’emblée l’intégralité de la stack d’agents locale. Les usages Cloud uniquement et de types uniquement évitent le coût du runtime local jusqu’au premier appel local, sans changement d’API. Le premier appel local entraîne un import unique, ensuite mis en cache.
Types TypeScript autonomes : les fichiers .d.ts publiés ne référencent plus de packages de workspace non publiés. Cela corrige les erreurs TS2305 et TS2307 avec skipLibCheck: false, ainsi que les any silencieux sur les types de flux comme TurnEndedUpdate.
ripgrep intégré : les exécutions shell locales utilisent le binaire rg intégré à la plateforme sans modifier votre PATH global. Sous Windows, le préfixage de ripgrep n’écrase plus la variable Path.
Composer 2 est redirigé vers Composer 2.5 : les clients SDK qui pointent encore vers les slugs composer-2 retirés sont automatiquement redirigés vers Composer 2.5, tout en conservant les variantes rapides, afin que les anciens scripts continuent de s’exécuter.
list_runs limité au workspace : Client, AsyncClient et Agent.list_runs acceptent un cwd facultatif, et le bridge revient par défaut au workspace de lancement. Cela corrige les résultats « agent introuvable » intempestifs lorsque le bridge s’exécute comme sous-processus.
Erreurs d’absence plus claires : rechercher un agent qui n’est pas dans le workspace résolu renvoie une erreur explicite indiquant qu’il est introuvable, au lieu d’une erreur interne opaque.
Version 0.1.6 et analyses : cursor-sdk 0.1.6 documente le circuit de publication Buildkite et étiquette l’utilisation du SDK comme sdk-python- pour des analyses plus claires.
Exécutez npm install @cursor/sdk ou pip install cursor-sdk pour mettre à niveau. Les scripts qui pointent vers composer-2 passent automatiquement à Composer 2.5, et requestId est un ajout sûr à votre schéma de métadonnées d’exécution. Consultez la documentation TypeScript et Python pour tous les détails.
Avec les canevas, les agents peuvent créer des artefacts interactifs, comme des tableaux de bord, des rapports et des outils internes, que vous pouvez partager avec votre équipe.
Cette version introduit le mode Design pour modifier les canevas plus rapidement, de nouvelles façons de comprendre l’utilisation du contexte, ainsi que d’autres améliorations pratiques.
Le mode Design est désormais disponible dans les canevas.
Sélectionnez et annotez directement des éléments de l’interface dans un canevas pour guider les modifications de Cursor, comme vous le feriez dans le navigateur. Au lieu de décrire la modification par écrit, vous pouvez simplement la pointer, donner votre avis et itérer plus rapidement.
#Rapport d’utilisation du contexte dans un canevas
Cursor peut désormais afficher l’utilisation du contexte de votre agent sous la forme d’un rapport interactif dans un canevas.
L’explorateur de contexte détaille la répartition des tokens entre le prompt système, les définitions d’outils, les règles, les skills, et bien plus encore. Comme il s’agit d’un canevas, vous pouvez poser des questions de suivi à l’agent, qui peut personnaliser le rapport pour répondre à vos questions spécifiques.
Cliquez sur le bouton Debug with Agent intégré au canevas pour demander à Cursor d’identifier des pistes pour réduire l’utilisation du contexte dans une nouvelle conversation.
Les canevas partagés peuvent désormais être ouverts en plein écran dans le Browser, ce qui facilite leur présentation à d’autres personnes.
Ajout de la possibilité pour les agents d’intégrer dans les canevas des boutons qui exécuteront un prompt spécifique lorsqu’on clique dessus.
Amélioration de la capacité de l’agent à corriger les erreurs de type dans les canevas.
Amélioration du style des composants et ajout de fonctionnalités supplémentaires de personnalisation des graphiques.
Les clients Enterprise peuvent désormais gérer plusieurs Teams Cursor depuis un seul endroit, avec des contrôles distincts en matière de sécurité, de gouvernance, de budget et de fonctionnalités pour chacune. Ces capacités sont désormais disponibles pour tous les clients Enterprise.
Une organisation est le conteneur principal de l’identité, de l’administration et des membres de votre entreprise. Elle offre aux administrateurs un point central pour consulter et gérer l’ensemble de leur installation Cursor, y compris une vue agrégée des dépenses et de l’utilisation des tokens de toutes les équipes.
Les équipes constituent l’unité opérationnelle d’un département, d’une région ou d’une filiale. C’est ce que les administrateurs gèrent aujourd’hui comme organisation Cursor. Nous avons rattaché cette unité à une organisation, afin que vous puissiez gérer plusieurs équipes, chacune avec ses propres paramètres de sécurité, de gouvernance, de dépense et de fonctionnalités.
Un utilisateur peut appartenir à plusieurs équipes, avec un rôle différent dans chacune. Pour les clients actuels, votre équipe existante est conservée et devient le point d’entrée par défaut pour la connexion, le routage et la création de nouvelles équipes.
Les groupes sont une collection légère d’utilisateurs pouvant s’étendre à plusieurs Teams ou exister au sein d’une même Team. Ils permettent d’attribuer à des cohortes d’utilisateurs un accès distinct aux modèles, des plafonds de dépenses et des permissions des agents, sans devoir créer une toute nouvelle Team. Lorsqu’un utilisateur appartient à plusieurs Teams ou groupes, le paramètre le plus permissif prévaut.
Auto-review est un nouveau mode d’exécution qui permet à Cursor de fonctionner plus longtemps, avec moins de demandes d’approbation et une exécution plus sûre.
Auto-review s’applique aux appels d’outil Shell, MCP et Fetch. Les appels figurant sur la liste d’autorisation s’exécutent immédiatement, et ceux qui peuvent être sandboxés s’exécutent dans le sandbox. Toutes les autres actions de l’agent sont envoyées à un sous-agent classifieur qui décide s’il faut autoriser l’appel, essayer une autre approche ou demander votre approbation.
Configurez votre mode d’exécution dans Settings > Cursor Settings > Agents > Run Mode. Vous pouvez également orienter l’agent classifieur en lui donnant des instructions personnalisées.
