Échec de la compaction de Codex avec "la protection de la réponse est indisponible" : c'est la recherche Web, pas votre contexte

Depuis le 8 octobre 2026, les longues sessions Codex échouent dès qu'elles essaient de se compacter. L'erreur indique stream disconnected before completion: response protection is unavailable, les tentatives de reprise n'aident pas, et la conversation ne peut pas continuer. La plupart des rapports concernent gpt-6.1-sol, mais gpt-6-astra et gpt-5.6-sol échouent de la même manière. Cela se produit derrière des proxies auto-hébergés, et cela apparaît également dans l'application officielle Codex avec une connexion directe à ChatGPT.

La réponse courte : le contexte n'est pas trop grand, et votre réseau n'est pas le problème. Le backend Codex de ChatGPT rejette désormais toute demande qui rejoue une recherche Web antérieure dans son historique sans déclarer également l'outil de recherche Web. La demande de compaction de Codex ne déclare aucun outil. Ainsi, une seule recherche Web au début d'une session suffit à faire échouer toutes les compactions ultérieures.

Que faire maintenant :

• Nouvelles sessions : définissez web_search = "disabled" jusqu'à ce que le backend ou Codex change.
• Sessions bloquées : déplacez le travail dans une nouvelle session. L'ancienne ne se compressera pas.
• Si vous maintenez votre propre passerelle devant Codex : ajoutez une déclaration de recherche Web lorsque l'historique contient une recherche. Le code est ci-dessous.

Le reste de cet article explique comment le déclencheur a été trouvé, quels correctifs communautaires ne fonctionnent pas, et comment sauver une session bloquée.

À quoi ressemble l'échec

Vous verrez l'un de ces messages dans Codex :

stream disconnected before completion: response protection is unavailable
Error running remote compact task: stream disconnected before completion: stream closed before response.completed

Le deuxième message est la version générique. Codex ne montre pas toujours l'erreur en amont, donc une compaction qui échoue avec "stream closed before response.completed" peut être le même problème. Le journal local de Codex a souvent Failed to run pre-sampling compact à côté.

En dessous, l'amont envoie l'une des deux choses. Parfois, c'est un HTTP 502 avec ce corps, qu'un utilisateur de ChatGPT Plus sur gpt-6.1-sol a également posté sur le forum des développeurs d'OpenAI :

{"message": "response protection is unavailable", "type": "internal_error"}

D'autres fois, c'est un HTTP 200 dont le flux se termine par un événement response.failed avec code: "upstream_error" et sans response.completed. Tout ce qui ne vérifie que le statut HTTP manque la deuxième forme et la signale comme un flux qui s'est terminé prématurément.

Le schéma est le même partout :

• Les tours normaux continuent de fonctionner. Seule la compaction échoue.
• Codex essaie environ cinq fois, puis abandonne. Dans les journaux d'une passerelle, chaque tentative échouée a pris de 2 à 13 secondes et a enregistré zéro jeton.
• Reprendre la session rencontre la même compaction, donc la session reste bloquée.
• Une nouvelle session fonctionne jusqu'à ce qu'elle rencontre les mêmes conditions.

Le déclencheur : une recherche dans l'historique, aucun outil de recherche dans la demande

Codex a un outil de recherche Web intégré. Lorsque le modèle l'utilise, un élément web_search_call entre dans l'historique de la conversation. Chaque demande ultérieure renvoie cet historique.

Les tours normaux déclarent l'outil dans tools, donc l'amont accepte la recherche rejouée. Une demande de compaction est différente. Codex envoie tout l'historique avec tools: [], car un résumé n'a pas besoin d'outils. Cela s'applique à la compaction locale, que Codex exécute pour des fournisseurs personnalisés, et à la compaction distante v2.

Autour du 6 octobre, le backend Codex de ChatGPT a commencé à rejeter les demandes qui rejouent un web_search_call mais ne déclarent pas web_search. Les développeurs qui ont capturé les demandes brutes l'ont précisé. Changer ou supprimer l'ID de l'élément de recherche ne fait aucune différence. Déclarer uniquement un outil fonctionnel échoue toujours. Déclarer web_search fait réussir la même demande.

Le même résultat apparaît avec le codex-cli officiel, non modifié connecté avec un compte ChatGPT. Un historique avec trois éléments de recherche a échoué à se compacter. Le même historique avec seulement ces éléments supprimés s'est bien compacté. Un deuxième rapporteur dans ce fil a capturé une demande de compaction avec un web_search_call et tools: []. Ajouter une déclaration web_search a corrigé le problème, tout comme la suppression de l'élément de recherche.

Cela explique pourquoi cela ressemble à un problème de taille de contexte. La compaction ne s'exécute que sur de longues sessions, et les longues sessions sont celles qui ont le plus de chances d'avoir utilisé la recherche à un moment donné. La recherche Web est également activée par défaut dans Codex (le mode par défaut est "cached"), donc une session peut contenir une recherche que l'utilisateur n'a jamais demandée.

Les preuves

Au moins quatre groupes ont réalisé des tests A/B indépendants et ont obtenu le même résultat. Les lignes ci-dessous combinent des tests publiés sur le suivi openai/codex et dans les trackers de problèmes de plusieurs projets de passerelles open-source. OpenAI n'a pas confirmé la règle ni répondu dans aucun de ces fils.

Les tests écartent la taille. Un testeur a fixé le seuil de compaction automatique à 2 000 jetons avec -c model_auto_compact_token_limit=2000. Une session sans utilisation d'outil s'est bien compactée. Une session qui avait effectué une recherche a échoué six fois de suite. Un autre testeur a constaté que la suppression des éléments de raisonnement n'a pas aidé, tandis que la suppression de l'élément de recherche unique l'a fait.

Dans un test, la version avec web_search déclarée a été complétée en 2,63 secondes et n'a effectué aucun nouvel appel de recherche. Déclarer l'outil ne fait pas rechercher à nouveau le modèle.

Ce que la communauté a essayé, et ce qui fonctionne réellement

Le fil LINUX DO qui a incité cet article a traversé la plupart des suppositions habituelles :

Quelques-unes de ces suggestions nécessitent plus d'explications.

Nginx et IP. Les délais d'attente et les connexions inactives peuvent causer d'autres erreurs "flux déconnecté", mais elles ne peuvent pas produire ce message. Les responsables des proxies impliqués ont confirmé que le message n'est pas généré par le proxy ; il vient du fournisseur en amont. Si le message est là, le réseau a réussi à transmettre la demande.

WebSocket. Les correctifs de passerelle qui ont fonctionné devaient couvrir le chemin WebSocket ainsi que HTTP, car les demandes WebSocket portent le même corps. Une session qui "s'est rétablie" après avoir changé de transport avait très probablement aucune recherche dans son historique.

Connexion officielle. Les rapports sur le suivi openai/codex incluent l'application de bureau et codex-cli connectés directement avec un compte ChatGPT, sans proxy impliqué. Au 10 octobre, ni Codex 0.162.1 ni les alphas 0.163.0 ne mentionnent de correctif, et les problèmes n'ont pas de réponse des mainteneurs.

Ce que vous pouvez faire maintenant

Désactiver la recherche Web pour les nouvelles sessions

Désactivez la recherche dans ~/.codex/config.toml :

web_search = "disabled"

La référence de configuration de Codex liste quatre valeurs : disabled, cached (la valeur par défaut), indexed et live. Les sessions démarrées avec --yolo ou un autre accès complet par défaut à live, donc définissez-le explicitement.

Appliquez cela aux nouvelles sessions. Une ancienne session a déjà des éléments web_search_call dans son historique. Avec la recherche désactivée, les tours normaux cessent également de déclarer l'outil, donc ces tours peuvent également commencer à échouer. Cela découle de la règle ci-dessus, mais personne n'a encore signalé l'avoir testé.

Le coût est que Codex ne peut pas rechercher sur le Web. Pour une session qui a besoin de recherche, ouvrez une nouvelle courte, ou faites en sorte que le modèle écrive les résultats dans un fichier que la longue session lit.

Sauver une session bloquée

Rien de votre côté ne fera compacter une session bloquée tant que le backend se comporte de cette manière. Pour conserver le travail :

1. Laissez la session bloquée telle quelle. Son historique est toujours sur disque sous ~/.codex/sessions/.
2. Démarrez une nouvelle session avec la recherche Web désactivée.
3. Dirigez-la vers le fichier de l'ancienne session, ou collez un court passage de transfert : l'objectif, les fichiers modifiés, les décisions prises, et ce qui reste.
4. Arrêtez d'envoyer des invites à l'ancienne session. Chaque tentative réessaie la compaction et échoue à nouveau.

Si vous maintenez votre propre passerelle

Le correctif qui fonctionne suit une règle. Si input contient un web_search_call et qu'aucun outil web_search* n'est déclaré, ajoutez-en un. Si l'appelant n'a déclaré aucun outil, définissez tool_choice sur "none" afin que l'outil ne puisse pas s'exécuter. Laissez input tel quel.

def declare_replayed_web_search(body: dict) -> dict:
    """Laissez l'amont accepter un web_search_call rejoué dans une demande sans outil."""
    items = body.get("input")
    if not isinstance(items, list):
        return body
    if not any(isinstance(i, dict) and i.get("type") == "web_search_call" for i in items):
        return body

    tools = body.get("tools") or []
    if any(isinstance(t, dict) and str(t.get("type", "")).startswith("web_search") for t in tools):
        return body

    caller_had_tools = bool(tools)
    # Index mis en cache uniquement : la déclaration existe pour satisfaire la vérification, pas pour rechercher.
    body["tools"] = tools + [{"type": "web_search", "external_web_access": False}]
    if not caller_had_tools:
        body["tool_choice"] = "none"
    return body

Les demandes Lite de réponses sont une exception. Elles retournent un 400 si web_search se trouve dans tools de niveau supérieur. Les correctifs fonctionnels le mettent dans le premier élément d'entrée additional_tools à la place, et gardent tout compaction_trigger final. L'alternative, qui consiste à retirer les éléments de recherche des demandes de compaction, fonctionne également, mais le résumé perd alors tout ce que la recherche a trouvé.

Si vous préférez ne pas dépendre du backend d'abonnement

Tous les rapports que nous avons trouvés passent par le backend d'abonnement de ChatGPT, le point de terminaison que Codex utilise avec une connexion ChatGPT. Ses règles ne sont pas documentées, et celle-ci a changé sans préavis.

Codex peut également utiliser l'API publique des réponses avec une clé API. Nous n'avons pas vu de rapport sur cette erreur sur ce chemin, mais nous n'avons pas non plus effectué la reproduction là-bas, donc considérez cela comme une observation, pas une garantie. Pour configurer Codex avec une clé AIHubMix, suivez le tutoriel Codex CLI :

model = "gpt-6.1-sol"
model_provider = "aihubmix"

[model_providers.aihubmix]
name = "AIHubMix"
base_url = "https://aihubmix.com/v1"
wire_api = "responses"
env_key = "AIHUBMIX_API_KEY"

Les tarifs de l'API s'appliquent par jeton, pas par abonnement. Les tarifs sont sur la page du modèle gpt-6.1-sol.

Liste de contrôle

• Le texte de l'erreur contient "la protection de la réponse est indisponible", ou la compaction échoue avec "flux fermé avant response.completed".
• Les tours normaux fonctionnent toujours et seule la compaction échoue.
• La session a utilisé la recherche Web à un moment donné, peut-être sans être demandée.
• Les nouvelles sessions ont web_search défini sur désactivé.
• Le travail bloqué a été déplacé vers une nouvelle session avec une note de transfert.
• Une passerelle que vous maintenez ajoute une déclaration de recherche Web lorsque l'historique contient une recherche.
• Les paramètres Nginx et réseau du proxy ont été laissés tels quels. Ils ne sont pas la cause.

FAQ

Que signifie "la protection de la réponse est indisponible" dans Codex ?
C'est une erreur du backend Codex de ChatGPT, pas de Codex lui-même ou de votre proxy. Depuis début octobre 2026, elle apparaît lorsqu'une demande rejoue une recherche Web antérieure mais ne déclare pas l'outil de recherche Web, ce que fait exactement une demande de compaction.

Mon espace de contexte est-il trop grand ?
Non. Les testeurs l'ont reproduit avec un seuil de compaction de 2 000 jetons, et des sessions de la même taille sans recherche se compactent normalement. Cela semble seulement lié à la taille parce que la compaction ne s'exécute que dans de longues sessions.

Est-ce que cela affecte l'application Codex officielle avec une connexion ChatGPT ?
Oui. Les utilisateurs de l'application de bureau et de codex-cli le signalent sur des connexions directes à ChatGPT sans proxy. Au 10 octobre 2026, aucune version de Codex ne mentionne de correctif.

Comment puis-je savoir si une session va rencontrer ce problème ?
Si la session a utilisé la recherche Web à un moment donné, sa prochaine compaction échouera très probablement. Codex enregistre chaque recherche comme un élément web_search_call dans les fichiers de session sous le dossier .codex/sessions.

Désactiver la recherche Web corrigera-t-il une session déjà bloquée ?
Probablement pas. L'ancien historique contient toujours la recherche, et une fois la recherche désactivée, les tours normaux peuvent cesser de déclarer l'outil et échouer également. Utilisez le paramètre pour les nouvelles sessions et déplacez le travail.

Changer pour WebSocket ou modifier nginx aide-t-il ?
Non. Le corps de la demande est le même dans les deux transports, et l'erreur vient de l'amont, donc les paramètres réseau ne peuvent pas l'éliminer. D'autres erreurs de flux peuvent provenir de délais d'attente, mais pas celle-ci.

Est-ce que cela se produit lorsque Codex utilise une clé API au lieu d'un abonnement ChatGPT ?
Tous les rapports jusqu'à présent concernent le backend d'abonnement. Personne ne l'a signalé sur l'API publique des réponses, bien que cela n'ait pas été testé directement.

Continuez à lire : la série GPT-6.1 Sol

• Si cette erreur est apparue juste après que vous ayez changé Codex en GPT-6.1 Sol, le guide de migration couvre les autres changements qui peuvent casser une configuration : Migrer vers GPT-6.1 Sol : 9 choses qui peuvent mal tourner
• Les longues sessions d'agent sont celles où les paramètres d'effort comptent le plus, pour la vitesse et pour la rapidité avec laquelle vous approchez de la compaction : Choisir un effort de raisonnement pour GPT-6.1 Sol : de faible à maximum

Sources

• Codex Desktop Windows : la compaction de contexte échoue toujours (openai/codex)
• La compaction distante échoue après avoir repris l'historique de web_search_call hébergé (openai/codex)
• La compaction distante de Codex échoue avec 502 "la protection de la réponse est indisponible" (Communauté des développeurs OpenAI)
• Référence de configuration de Codex (OpenAI)
• Tutoriel d'intégration Codex CLI + AIHubMix (AIHubMix)