Claude Code 2.1.285: allowedProviders schränkt Provider-Kontrolle ein
Das Update führt eine neue Einstellung allowedProviders ein, mit der sich eine Maschine auf einen von acht genehmigten Providern festlegen lässt. Admins allein können die Konfiguration ändern, und fehlgeschlagene Anfragen teilen sich künftig ein Retry-Budget mit ihrem Fallback.
Veröffentlicht am 10. Oktober • Zuerst erschienen auf raxxo.shop
Claude Code 2.1.285 erschien am 29. September 2026 mit einem Desktop-Flag, einer Plugin-Konfiguration und einer Provider-Sperre
Die neue Einstellung allowedProviders sperrt eine Maschine auf einen von acht zugelassenen Providern, nur für Admins
Eine fehlgeschlagene Anfrage wurde früher bis zu 21 Mal wiederholt, jetzt teilt sie sich ein Budget mit ihrem Fallback
claude --desktop und plugin configure sind heute schon nützlich, allowedProviders ist eine Enterprise-Einstellung, die man überspringen kann
Anthropic hat Claude Code 2.1.285 am 29. September 2026 veröffentlicht, und versteckt in dem, was wie ein routinemäßiges Punkt-Release aussieht, steckt eine Einstellung, die entscheidet, welche Cloud der gesamte Claude-Code-Traffic eines Unternehmens überhaupt berühren darf. Ich habe das Changelog am Morgen des Erscheinens gelesen, weil Claude Code das Werkzeug ist, mit dem ich RAXXO-Produkte baue, und dieses Release enthielt mehr, als der Versionssprung vermuten ließ. Zwei der Neuerungen habe ich am selben Tag aktiviert, an dem ich davon gelesen habe.
Ich hätte dieses Release fast übersprungen. Die Versionsnummer sah routinemäßig aus.
Sechs Neuerungen kamen zusammen mit einer langen Liste von Fixes. claude --desktop öffnet die Claude-Desktop-App im aktuellen Verzeichnis oder in einer bestimmten Sitzung mit --continue oder --resume <id>, sodass man eine Terminalsitzung an die GUI übergeben kann, ohne etwas neu eintippen zu müssen. claude plugin configure <plugin> zeigt die Optionen eines Plugins an und markiert, welche noch nicht gesetzt sind, und kann neue Werte, die es über stdin liest, mit --values-stdin speichern. Eine neue Form von claude plugin install --config, geschrieben als <server>.<key>=<value>, ermöglicht es, die eigenen Einstellungen eines gebündelten MCP-Servers bereits bei der Installation festzulegen, sodass ein Plugin, das Konfiguration benötigt, sofort funktioniert, statt halb eingerichtet herumzuliegen, bis jemand /plugin besucht und auf Configure klickt.
Dann gibt es noch CLAUDE_CODE_DISABLE_WEB_FETCH, eine Umgebungsvariable, die das WebFetch-Werkzeug vollständig abschaltet, und CLAUDE_CODE_NONSTREAMING_TIMEOUT_RETRIES, die begrenzt, wie oft eine abgelaufene nicht-streamende Fallback-Anfrage erneut gesendet wird. Die sechste, allowedProviders, verdient unten einen eigenen Abschnitt.
Dieses Release erscheint einen Tag nach 2.1.284, das Claude Sonnet 5.5 als Standard-Sonnet-Modell über die API einführte. Ich habe gestern über die Neuerungen von Sonnet 5.5 geschrieben, daher wiederhole ich hier die Modelldetails nicht. Bemerkenswert ist das Muster: ein Modell-Release, gefolgt einen Tag später von einem Tooling-Release, das Konfiguration und Zuverlässigkeit verschärft. Das ist seit Monaten der Rhythmus, und es ist ein nachvollziehbarer. Erst das Modell ausliefern, dann die Infrastruktur, mit der Teams tatsächlich kontrollieren können, wie es verwendet wird.
Die Fix-Liste ist lang, nach meiner Zählung mehr als achtzig Einträge, und deckt alles ab, von der Zustellung von Remote-Control-Nachrichten über das Tab-Verhalten in VS Code bis hin zum Umgang von redigierten Logs mit URL-Passwörtern. Ich werde nicht alle durchgehen.
Eine Handvoll davon ist für einen Solo-Entwickler wichtig genug, um weiter unten einen eigenen Abschnitt zu bekommen. Der Rest ist die Art von Wartung, die nie eine Schlagzeile macht, aber das Werkzeug davon abhält, an den Rändern zu verkommen, genauso wie die Entfernung des Subagent-Spawn-Limits im August keine Schlagzeilen machte, bis sie still und leise veränderte, wie lange eine Sitzung laufen konnte.
Es beschränkt, welche API-Provider eine Maschine überhaupt für Claude Code verwenden darf. Die Optionen sind die Anthropic API direkt, ein benutzerdefinierter Endpunkt, Amazon Bedrock, Mantle, Google Clouds Vertex AI, Microsoft Foundry, Claude Platform auf AWS oder ein Cloud-Gateway. Ein Administrator wählt einen oder mehrere dieser acht aus und trägt die Wahl in eine verwaltete Einstellungsdatei ein, die Art von Datei, die die Claude-Code-Dokumentation als über allen anderen Konfigurationsebenen stehend beschreibt. Die eigene settings.json eines Entwicklers, seine Projekteinstellungen und sogar auf der Kommandozeile übergebene Flags können diese Beschränkung weder erweitern noch aufheben. Sie wird durchgesetzt, nicht vorgeschlagen.
Man stelle sich ein Unternehmen vor, das aus Compliance-Gründen auf Bedrock standardisiert hat, vielleicht wegen Datenresidenz, vielleicht wegen einer bestehenden AWS-Ausgabenverpflichtung. Vor dieser Einstellung hielt nichts einen Entwickler davon ab, einen persönlichen Anthropic-API-Schlüssel in seine eigene Konfiguration einzufügen und Traffic still und leise außerhalb des genehmigten Pfades zu leiten. allowedProviders schließt diese Lücke auf Richtlinienebene, statt sich auf eine Slack-Nachricht zu verlassen, in der alle gebeten werden, bitte den richtigen Endpunkt zu verwenden.
Für ein Ein-Personen-Studio wie meines tut diese Einstellung nichts. Es gibt keine Flotte von Entwicklermaschinen, die abzusichern wäre, und keine verwaltete Einstellungsdatei über meinen eigenen. Ich habe keine IT-Richtlinie, die ich mir selbst auferlegen müsste.
Aber es verrät mir etwas darüber, wohin Claude Code sich entwickelt, je mehr Teams es übernehmen. Das Werkzeugumfeld rund um Governance wird immer spezifischer, eine durchsetzbare Einstellung nach der anderen, statt auf dem Niveau einer geschriebenen Richtlinie zu bleiben, die niemand tatsächlich überprüfen kann.
Ja, und der Grund dafür ist nicht allowedProviders. Zwei der sechs Neuerungen sind Dinge, die ich noch in dieser Woche verwenden würde. claude --desktop löst einen konkreten Ärger: Man startet etwas im Terminal und möchte dann die detailreichere Ansicht der Desktop-App, etwa das Diff-Panel oder die Artifact-Vorschau, ohne die Sitzung zu verlieren. Jetzt führe ich einfach claude --desktop --continue aus, und es macht genau dort weiter, wo das Terminal aufgehört hat.
claude plugin configure ist das andere. Ich habe eine Handvoll Plugins in meiner RAXXO-Tooling-Umgebung installiert, und mehr als einmal bin ich auf eine veraltete Einstellung gestoßen, die ich vergessen hatte zu setzen. Configure bei jedem auszuführen und genau zu sehen, welche Optionen leer sind, ist besser, als sich von Hand durch eine Einstellungsdatei zu wühlen.
Die Ergänzung <server>.<key>=<value> zu claude plugin install --config ist kleiner, löst aber ebenfalls einen echten Ärger. Ein gebündelter MCP-Server, der in einem Plugin mitgeliefert wird, lag bisher halb konfiguriert herum, bis ich daran dachte, /plugin zu öffnen und bis zu Configure durchzuklicken. Jetzt kann ich die Werte bei der Installation übergeben, und der Server funktioniert einfach, ohne zweiten Schritt, den man vergessen könnte. Es ist ein kleines Stück desselben Trends, den ich bemerkt habe, als MCP stateless wurde: Das Protokoll und das Werkzeugumfeld darum werden an den Rändern kontinuierlich verschärft, Release für Release.
Was ich überspringen würde: allowedProviders, aus den oben genannten Gründen, und CLAUDE_CODE_NONSTREAMING_TIMEOUT_RETRIES, es sei denn, ich stoße tatsächlich auf den speziellen Fehlerfall, für den sie gebaut wurde. Es ist eine schmale Umgebungsvariable für einen engen Randfall, nichts, was man vorsorglich setzt.
Nicht jede Neuerung braucht am ersten Tag einen Anwendungsfall.
Hier ist die konkrete Zahl, die man kennen sollte, versteckt in der Fix-Liste statt bei den Neuerungen. Eine fehlgeschlagene API-Anfrage wurde früher bis zu 21 Mal wiederholt, wenn Streaming kontinuierlich auf einen nicht-streamenden Fallback auswich, wobei jeder Versuch seine eigene Verzögerung hinzufügte. Jetzt teilen sich Streaming und sein Fallback ein Wiederholungsbudget, sodass eine Anfrage, die wirklich fehlschlägt, früher aufgibt, statt still und leise Minuten zu verschlingen.
Das ist die Art von Stocken, die ich vorher auf eine schlechte Verbindung geschoben hätte, ohne zu wissen, dass still und leise gegen ein Budget dieser Größe wiederholt wurde. Zu wissen, dass es eine Obergrenze gibt, und dass diese Obergrenze gerade enger gezogen wurde, verändert, wie lange ich warte, bevor ich annehme, dass etwas tatsächlich kaputt ist.
Einige der kleineren Fixes sind wichtiger, als ihre Einzeiler-Beschreibung vermuten lässt. Das Abschalten eines MCP-Servers, der mitten in einer Sitzung hinzugefügt wurde, ließ dessen Werkzeuge weiterhin verfügbar, was bedeutete, dass ein Server, von dem man dachte, er sei deaktiviert, trotzdem noch aufgerufen werden konnte. Das ist jetzt behoben, und es ist die Art von Bug, die leicht zu übersehen ist, weil nichts abstürzt, ein Werkzeug arbeitet einfach still weiter, obwohl es sollte.
Remote Control bekam ebenfalls eine echte Zuverlässigkeitskorrektur. Eine an eine Nachricht aus der Handy-App angehängte Datei verschwand früher, wenn der erste Download-Versuch fehlschlug, ohne Wiederholung, ohne Warnung. Jetzt wird bei einem Netzwerkfehler, Timeout oder Serverfehler bis zu zweimal wiederholt, bevor aufgegeben wird. Ich nutze Remote Control, um Sitzungen vom Handy aus anzustoßen, wenn ich nicht am Schreibtisch bin, meist um einen Screenshot von etwas Defektem anzuhängen. Diesen Screenshot still zu verlieren hätte bedeutet, den gesamten Vorgang von vorne zu machen.
Das Artifact-Werkzeug erhielt zwei zusammenhängende Fixes für ein Szenario, in dem man leicht landet: Veröffentlichen nach dem Zurückspulen einer Konversation mit Esc Esc. Vor diesem Release konnte eine Veröffentlichung nach einem Zurückspulen den neueren Inhalt einer Datei mit einer älteren Version überschreiben, die Claude nur in den zurückgespulsten Zügen gesehen hatte. Das wird jetzt verweigert, bis Claude die Datei zuerst neu liest, eine kleine Menge Reibung im Austausch dafür, dass neuere Arbeit nicht still und leise zerstört wird.
Cloud-Sitzungen, die nach einer Kompaktierung einer Konversation neu starten, verweigern auch keine Updates mehr an Artifacts, die die Sitzung bereits gelesen hatte, ein Bug, der das Fortsetzen einer langen Sitzung in der Cloud unzuverlässig gemacht hätte, genau dann, wenn man es einfach funktionieren lassen will.
Noch eine Erwähnung wert: Plugin- und Marketplace-Installationen über SSH ignorierten früher das SSH-Programm, das man in GIT_SSH oder im core.sshCommand der Git-Konfiguration gesetzt hatte, und fielen stattdessen still auf den Systemstandard zurück. Das ist die Art von Fix, die niemand bemerkt, bis man an einer Maschine mit einer nicht standardmäßigen SSH-Konfiguration sitzt und nicht herausfinden kann, warum eine Plugin-Installation immer wieder hängt.
In derselben Liste steckt auch eine kleinere Privacy-Korrektur. Geschwärzte Logs und Transkripte zeigten zuvor einen Teil des Passworts einer URL, oder sogar das komplette Passwort, wenn die URL ihr @-Zeichen als %40 statt als Klartext-Zeichen schrieb. Ein solches Detail übersieht man leicht, wenn man eine Schwärzungsregel erstellt, und es ist genau die Art von Lücke, die nur jemand findet, der tatsächlich Zeile für Zeile liest, wie ein "geschwärztes" Log aussieht.
Keines davon fällt in einer Demo auf. Es fällt auf, wenn man sich zum ersten Mal genau auf das Verhalten verlässt, das diese Fixes beheben, und es dann stillschweigend das Falsche tut.
Die Version 2.1.285 enthält nicht die Art von Breaking Changes, die Sonnet 5.5 einen Tag zuvor mit sich brachte. Es handelt sich um ein Maintenance-Release mit zwei wirklich nützlichen Ergänzungen für Solo-Entwickler, einer Enterprise-Einstellung, die für alle, die Claude Code allein nutzen, keinerlei Auswirkungen hat, und einer langen Fix-Liste, bei der drei oder vier Einträge wissenswert sind, selbst wenn man das komplette Changelog nie Zeile für Zeile liest.
Mein konkreter Plan: Ich aktualisiere heute, da nichts davon etwas kaputt macht, was ich nutze. Ich probiere claude --desktop --continue aus, wenn ich das nächste Mal während einer Sitzung die umfangreichere Ansicht möchte, und führe claude plugin configure über alle installierten Plugins aus, um zu prüfen, ob nichts noch auf einem veralteten Standardwert steht. allowedProviders ignoriere ich vollständig, es sei denn, ein Kunde oder Mitarbeiter benötigt Claude Code, das auf einen bestimmten Anbieter beschränkt ist; dann weiß ich genau, wo ich nachsehen muss. Und die Zahl der 21 Wiederholungsversuche behalte ich im Hinterkopf.
Es ist die Art von Detail, die einen Stillstand erklärt, den man schon einmal erlebt hat und wieder erleben wird, lange nachdem man vergessen hat, wo man darüber gelesen hat.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 10 • Originally published at raxxo.shop
Claude Code 2.1.285 shipped September 29, 2026 with a desktop flag, plugin config, and provider lockdown
The new allowedProviders setting locks a machine to one of eight approved providers, admin only
A failing request used to retry up to 21 times, now it shares one budget with its fallback
claude --desktop and plugin configure are useful today, allowedProviders is an enterprise setting to skip
Anthropic shipped Claude Code 2.1.285 on September 29, 2026, and buried inside what reads like a routine point release is a setting that decides which cloud a company's entire Claude Code traffic is allowed to touch. I read the changelog the morning it landed because Claude Code is the tool I use to build RAXXO products, and this one had more in it than the version bump suggested. Two of the additions I turned on the same day I read about them.
I almost skipped this release. The version number looked routine.
Six additions landed alongside a long list of fixes. claude --desktop opens the Claude desktop app on your current directory, or on a specific session with --continue or --resume <id>, so you can hand a terminal session to the GUI without retyping anything. claude plugin configure <plugin> shows a plugin's options and flags which ones are still unset, and can save new values it reads from stdin with --values-stdin. A new form of claude plugin install --config, written as <server>.<key>=<value>, lets you set a bundled MCP server's own settings at install time, so a plugin that needs configuration starts working immediately instead of sitting half set up until someone visits /plugin and clicks Configure.
Then there's CLAUDE_CODE_DISABLE_WEB_FETCH, an environment variable that turns off the WebFetch tool entirely, and CLAUDE_CODE_NONSTREAMING_TIMEOUT_RETRIES, which caps how many times a timed-out non-streaming fallback request gets resent. The sixth, allowedProviders, is the one worth its own section below.
This release comes one day after 2.1.284, which added Claude Sonnet 5.5 as the default Sonnet model on the API. I wrote about what shipped with Sonnet 5.5 yesterday, so I'm not repeating the model details here. What's worth noticing is the pattern: a model release followed a day later by a tooling release that tightens configuration and reliability. That's been the rhythm for months now, and it's a reasonable one. Ship the model, then ship the plumbing that lets teams actually control how it gets used.
The fix list is long, more than eighty items by my count, covering everything from Remote Control message delivery to VS Code tab behavior to how redacted logs handle URL passwords. I'm not going to walk through all of them.
A handful matter enough to a solo builder that they get their own section further down. The rest is the kind of maintenance that never makes a headline but keeps the tool from rotting at the edges, the same way removing the subagent spawn cap back in August didn't make headlines either, until it quietly changed how long a session could run.
It restricts which API providers a machine is permitted to use for Claude Code at all. The options are the Anthropic API directly, a custom endpoint, Amazon Bedrock, Mantle, Google Cloud's Vertex AI, Microsoft Foundry, Claude Platform on AWS, or a Cloud gateway. An administrator picks one or more of those eight and writes the choice into a managed settings file, the kind Claude Code documentation describes as sitting above every other configuration level. A developer's own settings.json, their project settings, and even flags passed on the command line can't widen or remove that restriction. It's enforced, not suggested.
Picture a company that has standardized on Bedrock for compliance reasons, maybe data residency, maybe an existing AWS spend commitment. Before this setting, nothing stopped a developer from pasting a personal Anthropic API key into their own config and quietly routing traffic outside the approved path. allowedProviders closes that gap at the policy level instead of relying on a Slack message asking everyone to please use the right endpoint.
For a one person studio like mine, this setting doesn't do anything. There's no fleet of developer machines to lock down and no managed settings file sitting above my own. I don't have an IT policy to enforce on myself.
But it tells me something about where Claude Code is heading as more teams adopt it. The tooling around governance keeps getting more specific, one enforceable setting at a time, rather than staying at the level of a written policy nobody can actually check.
Yes, and the reason isn't allowedProviders. Two of the six additions are things I'd use this week. claude --desktop solves a specific annoyance: starting something in the terminal, then wanting the richer view the desktop app gives you, like the diff panel or the artifact preview, without losing the session. Now I just run claude --desktop --continue and it picks up where the terminal left off.
claude plugin configure is the other one. I've got a handful of plugins installed across my RAXXO tooling, and more than once I've hit a stale setting I forgot I'd left unset. Running configure on each one and seeing exactly which options are blank beats digging through a settings file by hand.
The <server>.<key>=<value> addition to claude plugin install --config is smaller but solves a real annoyance too. A bundled MCP server that ships inside a plugin used to sit half configured until I remembered to open /plugin and click through to Configure. Now I can pass the values at install time and the server just starts working, no second step to forget. It's a small piece of the same trend I noticed when MCP went stateless: the protocol and the tooling around it keep getting tightened at the edges, one release at a time.
What I'd skip: allowedProviders, for the reason above, and CLAUDE_CODE_NONSTREAMING_TIMEOUT_RETRIES unless I actually hit the specific failure it's built for. It's a narrow env var for a narrow edge case, not something to set defensively.
Not every addition needs a use case on day one.
Here's the concrete number worth knowing, buried in the fix list rather than the additions. A failing API request used to get retried up to 21 times when streaming kept failing over to a non-streaming fallback, each retry adding its own delay. Now streaming and its fallback share one retry budget, so a request that's genuinely failing gives up sooner instead of quietly eating minutes. That's the kind of stall I'd have blamed on a bad connection before, without knowing it was quietly retrying against a budget that size. Knowing there's a ceiling, and that the ceiling just got tighter, changes how long I wait before I assume something's actually broken.
A few of the smaller fixes matter more than their one-line description suggests. Switching off an MCP server that was added mid-session used to leave its tools available anyway, which meant a server you thought you'd disabled could still get called. That's fixed now, and it's the kind of bug that's easy to miss because nothing crashes, a tool just quietly keeps working when it shouldn't.
Remote Control got a real reliability fix too. A file attached to a message sent from the phone app used to disappear if the first download attempt failed, no retry, no warning. It now retries up to twice on a network error, timeout, or server error before giving up. I use Remote Control to nudge sessions from my phone when I'm away from the desk, usually to attach a screenshot of something broken. Losing that screenshot silently would have meant redoing the whole exchange.
The Artifact tool picked up two related fixes around a scenario that's easy to land in: publishing after rewinding a conversation with Esc Esc. Before this release, a publish after a rewind could overwrite a file's newer content with an older version Claude had only seen in the rewound turns. It's now refused until Claude re-reads the file first, which is a small amount of friction in exchange for not silently destroying newer work. Cloud sessions that restart after a conversation gets compacted also stopped refusing updates to artifacts the session had already read, a bug that would have made resuming a long session in the cloud unreliable right when you need it to just work.
One more worth a mention: plugin and marketplace installs over SSH used to ignore whatever SSH program you'd set in GIT_SSH or your git config's core.sshCommand, silently falling back to the system default instead. That's the kind of fix nobody notices until they're on a machine with a nonstandard SSH setup and can't figure out why a plugin install keeps hanging.
There's also a smaller privacy fix buried in the same list. Redacted logs and transcripts used to show part of a URL's password, or all of it when the URL wrote its "@" symbol as "%40" instead of the plain character. It's an easy detail to miss when you're building a redaction rule, and exactly the kind of gap that only gets found by someone actually reading what a "redacted" log looks like line by line.
None of these show up in a demo. They show up the first time you're relying on exactly the behavior they fix, and it quietly does the wrong thing instead.
2.1.285 doesn't carry the kind of breaking changes Sonnet 5.5 shipped with the day before. It's a maintenance release with two genuinely useful additions for a solo builder, one enterprise setting that changes nothing for anyone running Claude Code alone, and a long fix list where three or four entries are worth knowing even if you'll never read the full changelog line by line.
My actual plan: update today, since none of this breaks anything I run. Try claude --desktop --continue the next time I want the richer view mid-session, and run claude plugin configure across my installed plugins to check nothing's sitting on a stale default. Ignore allowedProviders entirely unless a client or collaborator ever needs Claude Code locked to a specific provider, at which point I'll know exactly where to look. And keep the 21-retry number in the back of my head. It's the kind of detail that explains a stall you've already seen and will see again, long after you've forgotten where you read about it.