Limite Claude Code : augmenter la sortie des outils

En bref : quelle limite Claude Code modifier ?

Les deux paramètres sont arrivés dans Claude Code 2.1.261 le 4 septembre 2026. Ils répondent à un problème bien précis : la commande s’est exécutée et les éléments recherchés existent, mais le modèle n’en a reçu qu’une trop petite partie directement.

Il s’agit de limites en caractères, pas en tokens. Imaginez la largeur d’une trappe de livraison : l’agrandir permet à Claude de recevoir davantage de logs d’un seul coup, mais chaque ligne supplémentaire occupe aussi de la place dans la session.

Commencez par récupérer la sortie manquante

Augmenter la limite ne doit pas être le premier réflexe. Récupérez d’abord le log complet, repérez l’information absente, puis demandez-vous si cette catégorie de commandes mérite réellement plus de place dans la sortie directe.

Pour une commande réussie, Claude Code envoie par défaut environ 30,000 caractères directement. Si la sortie est plus longue, Claude reçoit un court aperçu de son début ainsi que le chemin du fichier dans lequel elle a été enregistrée, au sein du répertoire de session. Demandez à Claude de lire ce fichier ou d’y effectuer une recherche. Cette approche consomme généralement moins de contexte que d’injecter le log entier à chaque commande similaire.

Le comportement diffère en cas d’échec. Lorsque la sortie est trop longue, Claude reçoit un extrait d’environ 10,000 caractères composé du début et de la fin, sans chemin vers un fichier sauvegardé. Si la trace d’erreur manquante se trouve au milieu, relancez la commande en enregistrant toute sa sortie dans un fichier connu :

# Baseline: run the command normally and observe where its inline result stops
npm test

# Recovery for a failing run: keep the whole log at a path Claude can inspect
mkdir -p .claude/logs
test_status=0
npm test > .claude/logs/test-full.log 2>&1 || test_status=$?
wc -c .claude/logs/test-full.log
tail -n 120 .claude/logs/test-full.log
printf 'test exit code: %s\n' "$test_status"

Le fichier .claude/logs/test-full.log devient alors la source de référence. Demandez à Claude d’y rechercher les noms des tests en échec, les exceptions et les traces d’appels, plutôt que de coller l’intégralité du fichier dans la conversation. Le code de sortie d’origine reste ainsi visible parmi les éléments de diagnostic.

Les commandes passées en arrière-plan indiquent déjà le fichier dans lequel elles écrivent. Anthropic signale désormais TaskOutput comme obsolète et recommande d’utiliser Read sur ce chemin, une méthode souvent plus propre pour récupérer la sortie.

N’augmentez que la limite réellement utile

Si une même commande réussie dépasse régulièrement la fenêtre par défaut, augmentez uniquement bashOutputMaxChars. Une valeur initiale de 60,000 caractères double à peu près la quantité affichée directement, sans adopter d’emblée le plafond de 128,000 caractères :

{
  "bashOutputMaxChars": 60000
}

Placez cet objet dans le fichier correspondant à la portée du problème :

Exécutez /status pour vérifier quel fichier de paramètres Claude Code a chargé. Relancez ensuite la même commande et comparez son résultat wc -c à la valeur retenue. Si le log reste plus long, Claude Code doit à nouveau fournir un aperçu et le chemin du fichier sauvegardé pour une commande réussie.

Pour une tâche en arrière-plan, utilisez plutôt taskOutputMaxChars. La même plage de 4,000 à 128,000 caractères s’applique. Si une tâche terminée dépasse encore la limite, Claude reçoit les caractères les plus récents ; le fichier de sortie reste donc indispensable pour consulter l’historique complet.

Les deux paramètres prennent le pas sur les anciennes variables d’environnement équivalentes. Lorsque bashOutputMaxChars est présent, Claude Code ignore BASH_MAX_OUTPUT_LENGTH. Avec taskOutputMaxChars, il ignore TASK_MAX_OUTPUT_LENGTH. Cumuler les deux mécanismes complique le diagnostic : conservez une seule source de référence.

Le coût en contexte se déplace, il ne disparaît pas

Faire passer une commande réussie de la valeur par défaut d’environ 30,000 caractères à 60,000 peut éviter une lecture de fichier supplémentaire lorsque le résultat complet tient dans cette fenêtre. Mais cela peut aussi ajouter immédiatement jusqu’à environ 30,000 caractères dans la session. À 128,000, la fenêtre autorisée représente un peu plus de quatre fois celle d’une commande réussie par défaut.

Il n’existe aucune conversion fixe et sérieuse de cette hausse en tokens ou en dollars. Le code source, le JSON, le texte courant et l’Unicode ne sont pas tokenisés de la même manière ; la facturation ou le quota dépend aussi du modèle et du type de compte. En pratique, la règle budgétaire est plus simple :

• Augmentez la limite lorsque la partie omise contient des éléments dont Claude a besoin de façon répétée.
• Gardez la valeur par défaut si une recherche ciblée dans le fichier sauvegardé suffit.
• Réduisez une exception de projet une fois l’enquête sur les logs bruyants terminée.
• N’augmentez pas les deux paramètres parce qu’une seule commande a été tronquée une fois.

Ce réglage complète les méthodes permettant de réduire le coût en contexte des skills Claude Code. Les métadonnées des skills occupent du contexte avant même le début du travail ; les sorties d’outils arrivent pendant l’exécution. Corriger l’un ne corrige pas l’autre.

Sept workflows qui en profitent, par ordre d’intérêt

1. Synthèses de tests dans un monorepo

Lorsqu’un responsable de livraison exécute une vaste suite de tests, la commande peut réussir tout en produisant des synthèses par package et des avertissements qui dépassent la fenêtre directe par défaut. Augmenter bashOutputMaxChars pour ce dépôt peut conserver toute la synthèse dans le premier résultat. À condition que la sortie tienne dans la limite choisie, le gain tient à la réduction des lectures supplémentaires lors de chaque contrôle de livraison.

2. Environnements d’intégration en arrière-plan

Une équipe plateforme peut laisser tourner un serveur local, un émulateur ou un environnement d’intégration en tâche de fond pendant que Claude travaille ailleurs. En augmentant taskOutputMaxChars, Claude reçoit davantage de sorties récentes lorsqu’il consulte cette tâche. Le fichier complet reste important, car le paramètre privilégie les derniers caractères après un dépassement.

3. Revue des avertissements du compilateur et du linter

Une équipe applicative peut terminer un build avec succès tout en générant des milliers d’avertissements. Une fenêtre plus large pour les commandes réussies révèle ceux des packages qui resteraient sinon au-delà de l’aperçu. Ce choix est pertinent lorsque l’équipe résorbe un arriéré d’avertissements et accorde plus de valeur au résultat complet qu’à une session légère.

4. Simulations de migration de base de données

Un ingénieur data peut exécuter avec succès une simulation qui affiche chaque modification de schéma envisagée. Garder ce plan, dans des limites maîtrisées, directement dans la session permet à Claude de comparer les changements associés au sein d’un même résultat. La continuité de la revue y gagne, mais uniquement après avoir exclu du log les secrets et les identifiants de production.

5. Audits des dépendances et des licences

Un ingénieur sécurité peut recevoir un long inventaire réussi dont les résultats sont répartis jusque dans la partie centrale. Une limite Bash propre au dépôt peut rendre l’intégralité de ce rapport borné disponible pendant une session d’audit. Le risque qu’un package passe inaperçu simplement parce qu’il se trouvait hors de l’aperçu diminue ainsi.

6. Enquête sur les tests instables

Un ingénieur QA a besoin de la séquence exacte entourant une panne intermittente, alors que le résultat de la commande en échec ne montre qu’un extrait du début et de la fin. Relever le paramètre Bash ne change pas ce comportement. Enregistrez la nouvelle exécution dans un fichier connu, puis recherchez une plage horaire ou un nom de test précis : vous conservez ainsi les éléments utiles sans saturer la session.

7. Générateurs de code très bavards

Un développeur peut avoir besoin, une seule fois, du rapport de réussite complet d’un générateur, par exemple pour contrôler chaque fichier créé ou ignoré. Un paramètre local temporaire peut élargir le résultat le temps de cette vérification, puis être retiré. Vous obtenez ainsi un audit plus lisible des changements générés sans transformer une exception ponctuelle en règle permanente pour toute l’équipe.

Si l’organisation des fichiers de paramètres ne vous est pas familière, le guide complet de configuration de Claude Code replace l’outil dans son contexte avant d’aborder ce réglage précis.

Quel produit mérite d’être construit ?

Meilleure piste : un orchestrateur de logs sensible au contexte

Concevez un wrapper de commandes local destiné aux équipes de développement assistées par IA. Il doit systématiquement conserver le log brut, mesurer son nombre de caractères, indexer les plages importantes et renvoyer un manifeste compact avec leurs chemins. Il ne doit recommander une limite directe propre à la commande que lorsque les mêmes éléments sont consultés à plusieurs reprises.

La demande voisine reste limitée, mais son potentiel commercial est précis. Aux États-Unis, les données de mots-clés estiment à 320 le nombre de recherches mensuelles pour log analyzer, avec une intention transactionnelle et un coût par clic de $60.95. Les budgets actuels consacrés à l’observabilité confirment que la gestion des logs a déjà des acheteurs : Better Stack affiche une offre de 40 GB de logs, traces et métriques à $25 par mois avec facturation annuelle, ainsi qu’un chat SRE IA à $5 par million de tokens. Ces produits répondent à un besoin plus large, mais ces dépenses montrent que les équipes paient pour extraire le signal de leurs logs.

La plus petite version commercialisable réunit un wrapper multiplateforme, un répertoire local de logs, un compteur de caractères, un index des échecs et un rapport que Claude peut consulter de façon sélective. La confiance constitue le principal obstacle. Les logs de build peuvent contenir des identifiants, des données clients et des chemins propriétaires : le stockage local en priorité et des règles de masquage explicites sont des composants du produit, pas des finitions. C’est la piste la plus solide, car elle traite la décision récurrente qui motive le paramètre, et pas seulement la modification du JSON.

Piste de niche : un outil de préparation des preuves de test

Concevez un adaptateur qui exécute les frameworks de test courants, conserve le log intact et remet à Claude une courte carte des éléments disponibles : noms des tests en échec, plages des traces d’appels et chemin du fichier à consulter pour approfondir. Les équipes QA et d’expérience développeur seraient prêtes à payer lorsqu’une seule suite bruyante reproduit chaque jour le même travail de diagnostic.

La requête test failure analysis génère environ 20 recherches mensuelles aux États-Unis, avec une concurrence faible et une difficulté de mot-clé de 11. La demande ne suffit pas à soutenir la promesse d’un SaaS autonome généraliste. Elle justifie toutefois une fonctionnalité ciblée dans l’orchestrateur de logs, ou un outil payant destiné aux équipes dont les suites de tests sont coûteuses.

Un MVP exige des adaptateurs pour deux ou trois outils d’exécution, un stockage déterministe des logs bruts et une vue côte à côte des éléments extraits et des lignes sources. La fragmentation est le principal écueil : Jest, Pytest, Gradle et les outils maison ne présentent pas les échecs de la même façon, et un extracteur trop sûr de lui risque de supprimer l’indice dont Claude avait besoin. Le fichier brut doit toujours rester accessible en une lecture.

À quoi ce réglage ne sert-il pas ?

Ce paramètre n’accorde pas davantage de messages Claude, ne relève pas un quota hebdomadaire, n’agrandit pas la fenêtre de contexte d’un modèle et ne contourne pas une limite d’utilisation des outils. Il ne modifie que le traitement du nombre de caractères affichés directement pour deux circuits de résultats locaux de Claude Code.

Il ne rend pas non plus une sortie illimitée sans danger. Les sorties de commandes réussies sauvegardées par Claude Code sont tronquées au-delà de 64 MiB, et une commande est arrêtée si son flux dépasse 5 GB. Surtout, un résultat direct de 128,000 caractères peut évincer du contexte utile à la conversation. Le maximum est un garde-fou, pas une recommandation.

Les sessions cloud ajoutent un piège lié à la portée. Elles lisent un fichier .claude/settings.json committé, mais pas les fichiers de paramètres utilisateur ou locaux de votre machine. Seuls les paramètres d’organisation administrés côté serveur leur parviennent. Si une valeur semble ignorée, consultez /status avant de la modifier à nouveau.

Si vous souhaitez construire un workflow de développement sensible au contexte autour de vos propres systèmes de tests et de logs, les systèmes d’IA en production constituent le bon point de départ.