Cloudflare oddaje agentom 2900 poleceń — logowanie nadal wymaga człowieka

28 września 2026 r. Cloudflare udostępnił otwartą betę cf: nowego narzędzia wiersza poleceń, które ma objąć ponad 3000 operacji API, podczas gdy Wrangler obsługuje około 280 ścieżek poleceń. Programista może więc powierzyć agentowi znacznie szerszy zakres zadań na platformie Cloudflare, od pracy z Workers po zarządzanie usługami konta. Samo rozszerzenie katalogu nie daje jednak agentowi uprawnień do tych działań.

Cloudflare opisuje ponad 2900 poleceń cf dla agentów oraz interaktywne logowanie przez cf auth login, które otwiera w przeglądarce stronę zatwierdzenia dostępu przez człowieka. Agent może wcześniej znaleźć polecenie i obejrzeć plan żądania bez danych dostępowych. Do wykonania operacji na koncie potrzebuje poświadczeń z odpowiednimi uprawnieniami; w pracy bez nadzoru może korzystać z tokenu API zamiast logowania w przeglądarce.

Co zmienia szerszy katalog cf

cf ma sięgać do publicznego API Cloudflare, a nie tylko do zadań związanych z projektem Workers. Polecenia są generowane ze schematów API za pomocą projektu Forge. Dzięki temu katalog może obejmować między innymi tworzenie baz D1, działania dotyczące Cloudflare Access i WAF oraz operacje na domenach. Liczba operacji API z ogłoszenia premiery i liczba poleceń z dokumentacji opisują różne miary zakresu narzędzia; nie są dwoma wynikami tego samego liczenia.

Przy tak dużym katalogu istotne jest wyszukiwanie. Polecenie cf cli search "create D1 database" przyjmuje opis zadania i lokalnie zwraca pasujące komendy, bez kontaktu z kontem. Po wybraniu cf d1 create można uruchomić cf schema d1 create, aby zobaczyć metodę i ścieżkę żądania oraz wymagane pola. Schemat pomaga ustalić parametry przed wywołaniem API, choć dla niektórych złożonych treści żądań lista pól bywa niepełna i trzeba sprawdzić opis samej operacji.

Wyniki większości poleceń API cf mają postać JSON, więc agent może odczytywać konkretne pola bez rozpoznawania tabel przeznaczonych dla człowieka. Komunikaty i błędy trafiają na standardowe wyjście błędów. Ta zmiana ułatwia automatyczne przetwarzanie odpowiedzi, ale nie zmienia skutków polecenia: utworzenie zasobu, zmiana reguły ochrony albo usunięcie Workera nadal są operacjami na rzeczywistym koncie.

Instalacja i granica ręcznej autoryzacji

Minimalna ścieżka zaczyna się od npm install --global cf. Po instalacji można wyszukać polecenie opisem zadania, sprawdzić jego schemat i użyć opcji --dry-run. Przykładowo cf d1 create --name my-database --dry-run wypisuje planowane żądanie jako JSON, bez wysyłania go i bez konieczności podawania poświadczeń. Dopiero uruchomienie polecenia bez tej opcji podejmuje próbę utworzenia bazy.

Gdy zadanie wymaga dostępu do konta, użytkownik uruchamia cf auth login i sam zatwierdza dostęp na otwartej stronie. Instrukcja dla agenta może wskazywać, by korzystał z cf przy zadaniach Cloudflare, lecz nie powinna przekazywać mu etapu zatwierdzania logowania. Ręczna zgoda następuje przy uwierzytelnieniu; późniejsze komendy działają w granicach uprawnień uzyskanych przez użyte poświadczenia, dlatego warto ocenić je przed rozpoczęciem automatyzacji.

Inaczej wygląda praca bez obecności człowieka, na przykład w CI. Taki agent nie ukończy cf auth login i może otrzymać token przez zmienną CLOUDFLARE_API_TOKEN; token ma pierwszeństwo przed zapisanym logowaniem. Można też powiązać osobny profil z katalogiem lokalnego projektu. Te sposoby rozdzielają poświadczenia między zadaniami, ale same nie ograniczają ich zakresu: o dostępnych operacjach decydują prawa nadane tokenowi lub profilowi.

Gdzie nadal potrzebny jest Wrangler

Projekt oparty na wrangler.jsonc albo wrangler.toml może nadal używać Wranglera do uruchamiania, budowania i wdrażania Workera. W takim projekcie agent nie powinien wykonywać cf dev, cf build ani cf deploy bez cloudflare.config.ts: polecenia mogą utworzyć nową konfigurację pomijającą ustawienia Wranglera albo zakończyć się błędem. Dotyczy to konfiguracji projektu, nie całego katalogu cf. Polecenia dotyczące konta lub zasobów można wykorzystywać także w katalogu istniejącego projektu, bez jego migracji.

Jeżeli zespół chce przenieść sam projekt, cf migrate --dry-run pokazuje plan zmian bez zapisywania plików. Po cf migrate trzeba przejrzeć wygenerowany cloudflare.config.ts i rozstrzygnąć pozostawione uwagi TODO(@cloudflare); nierozwiązane wymagane elementy zatrzymują budowanie. Wybór narzędzia zależy więc od czynności: Wrangler pozostaje właściwy dla bieżącego cyklu pracy niemigrowanego projektu, a cf rozszerza dostęp do zadań dotyczących konta i produktów poza dotychczasowym zakresem Wranglera.

Jak opisuje Beyond the News, po zakończeniu otwartej bety Cloudflare planuje ostatnią dużą wersję Wranglera kierującą użytkowników do cf oraz 18 miesięcy wsparcia utrzymaniowego. Data zakończenia bety nie została podana. To pozostawia czas na ocenę istniejących wdrożeń, zwłaszcza tam, gdzie migracja zmienia sposób budowania projektu i jego konfigurację.

Uprawnienia ważniejsze niż liczba poleceń

Najwęższych uprawnień wymagają zadania, których skutek wykracza poza pojedynczy odczyt: wdrożenie Workera, zmiana reguł WAF, operacje na domenach i usuwanie zasobów. Jeżeli agent ma tylko znaleźć właściwą komendę lub przygotować podgląd żądania, nie potrzebuje dostępu do konta. Przy zadaniu wykonywanym bez nadzoru token powinien pozwalać wyłącznie na operacje konieczne do tego zadania, zamiast otwierać agentowi cały zakres konta.

Szczególnej uwagi wymaga --force. W sesji nieinteraktywnej polecenie usuwające zasób bez tej opcji może wypisać Aborted. i zakończyć się kodem 0, mimo że niczego nie usunięto. Z kolei --force bywa parametrem przekazywanym do samego API: cf workers delete --force może usunąć Workera, do którego odwołują się inne Workery. Agent interpretujący sam kod zakończenia jako dowód wykonania zadania może więc błędnie ocenić wynik.

Podgląd żądania i ograniczony token rozwiązują różne problemy. --dry-run pokazuje plan przed wykonaniem, a zakres tokenu wyznacza to, co agent będzie mógł zrobić po uruchomieniu komendy bez podglądu. Dla zespołu korzystającego już z Wranglera najbezpieczniejszy podział pracy wynika z tych granic: zachować obecny sposób wdrażania niemigrowanego Workera, a agentowi udostępniać tylko te operacje cf, których wymaga konkretne zadanie.

Przeczytaj także:

• GitHub zażąda ponownego logowania przed zmianą tokenu lub webhooka
• Etykieta AI na YouTube: scenariusz jej nie wymaga, realistyczny deepfake tak