Es handelt sich wahrscheinlich um ein fehlerhaftes Axios-/Header-Handling-Problem, das in dem neuesten Cloud-Update eingeführt wurde. Ich könnte mich allerdings irren.
@Gianluca hat sich die GitHub-Issue genauer angesehen – der Fehler liegt im globalen Axios-Request-Interceptor von n8n für jede URL, die mit https://api.openai.com/ beginnt. applyVendorHeaders weist config.headers einem einfachen Objekt zu, das keine setContentType-Methode besitzt, wodurch der Interceptor downstream abstürzt. Dies betrifft jeden Code-Pfad, der über den n8n-Request-Helfer läuft (HTTP-Request-Knoten, Code-Knoten, AI-Agent-Knoten), unabhängig vom Anmeldeinformations-Typ.
Das n8n-Team hat dies als Issue #29471 verfolgt, mit dem Status „in-linear, team-assigned“, sodass eine Korrektur bevorsteht. Bis dahin:
Der LangChain-OpenAI-Knoten (@n8n/n8n-nodes-langchain.openAi) nutzt einen anderen SDK-Pfad und könnte den Interceptor umgehen – einen Versuch wert für die von ihm abgedeckten Operationen.
Falls Sie das raw vector_stores-Endpunkt benötigen, leiten Sie die Anfrage über einen kleinen Proxy weiter (Cloudflare Worker oder eine beliebige URL, die an api.openai.com weiterleitet), damit die URL nicht den Interceptor auslöst.
Bestätigter Fehler — Der globale Axios-Interceptor von n8n stürzt bei jeder URL ab, die mit api.openai.com/ beginnt. applyVendorHeaders überschreibt config.headers in ein einfaches Objekt, woraufhin ein nachgelagerter Interceptor setContentType nicht mehr aufrufen kann und abstürzt. Dies betrifft HTTP-Request, Code (helpers.httpRequest) und AI Agent – alles, was über den n8n-Request-Helfer läuft. Der Credential-Typ spielt keine Rolle, da die Übereinstimmung auf URL-Basis erfolgt.
Die sauberste Workaround-Lösung, bis n8n einen Patch bereitstellt, ist ein Cloudflare Worker-Proxy. Einrichtung in ca. 5 Minuten, der Free-Tier bewältigt 100.000 Anfragen/Tag.
