Scheduler w Claude Code: /loop, rutyny w chmurze i GitHub Actions

Claude Code · JSystems - artykuł standalone

Pytanie, które prędzej czy później zadaje każdy, kto na poważnie używa Claude Code: czy da się ustawić, żeby coś robił sam, cyklicznie, w tle - bez trzymania otwartego okna w terminalu i bez dłubania w systemowym cronie? Odpowiedź brzmi: tak, ale wszystko zależy od tego, którego z czterech mechanizmów użyjesz. Jeden działa tylko przy otwartej konsoli, inny biegnie w chmurze nawet przy wyłączonym laptopie. W tym artykule przejdziemy je po kolei - od najprostszego /loop aż po rutyny uruchamiane zdalnie.

Zacznijmy od /loop - pętla w aktywnej sesji

Najprostszy sposób, żeby Claude Code coś powtarzał, to komenda /loop. Wpisujesz prompt i interwał, a Claude wykonuje go raz za razem, w odstępach które podasz - dopóki sesja jest otwarta. To pętla wewnątrz Twojej bieżącej konwersacji, a nie osobny proces.

Wywołać /loop możesz na trzy sposoby:

• Z jawnym odstępem - /loop 30m sprawdź status deploya. Co 30 minut Claude wykona ten sam prompt. Odstęp podajesz w naturalnym zapisie (5m, 30m, 1h).
• Bez odstępu - /loop sprawdzaj, czy testy CI przeszły. Claude sam dobiera tempo w zależności od sytuacji, w widełkach od 1 minuty do 1 godziny.
• Samo /loop - uruchamia wbudowany prompt utrzymaniowy. Własny domyślny prompt zdefiniujesz w pliku .claude/loop.md (w projekcie) albo ~/.claude/loop.md (globalnie).

Własny domyślny prompt: plik loop.md

Gdy uruchomisz samo /loop bez własnego promptu, Claude Code szuka domyślnej instrukcji w plikach loop.md - najpierw w projekcie (.claude/loop.md), potem globalnie (~/.claude/loop.md), a jeśli żadnego nie ma, sięga po wbudowany prompt utrzymaniowy. Plik projektowy ma pierwszeństwo przed globalnym, więc każde repozytorium może mieć własną „pętlę dyżurną".

Zawartość to zwykły Markdown z instrukcją, co Claude ma zrobić w każdym cyklu. Przykład .claude/loop.md, który pilnuje zielonego builda:

# Pętla dyżurna projektu - wykonywana w każdym cyklu /loop

Sprawdź, czy w gałęzi pojawiły się nowe commity (git fetch + git log).
Uruchom testy: npm test.
Jeśli któryś test nie przechodzi - znajdź przyczynę, napraw i zrób commit z opisem.
Jeśli build jest zielony - nie zmieniaj niczego i poczekaj na kolejny cykl.
Nigdy nie wysyłaj zmian bez zielonych testów.

Globalny ~/.claude/loop.md przyda się do dyżuru niezależnego od projektu - na przykład pilnowania długiego procesu w tle:

# Globalna pętla dyżurna (~/.claude/loop.md)

Sprawdź status długiego zadania w tle (np. ogon logu /tmp/build.log).
Gdy zadanie się skończy - podsumuj wynik w jednym zdaniu.
Gdy nadal trwa - zgłoś krótki status i czekaj dalej.

Pod spodem działa kilka mechanizmów, o których warto wiedzieć. Zadania pętli są rozrzucane w czasie (jitter) - do nich dokładany jest losowy poślizg (do 30 minut przy zadaniach cyklicznych, do 90 sekund przy jednorazowych), żeby wiele pętli nie uderzało w API jednocześnie. Zaplanowane zadania wygasają po 7 dniach i są przywracane po wznowieniu sesji przez --resume lub --continue, o ile jeszcze nie wygasły.

Najważniejsze ograniczenie jest jednak takie: pętla żyje wyłącznie w otwartej sesji. Zadania odpalają się tylko wtedy, gdy Claude Code jest uruchomiony i bezczynny - czeka na kolejny cykl. Zamkniesz okno albo uśpisz komputer i pętla staje. To świetne narzędzie do pilnowania czegoś w trakcie pracy (czy build się skończył, czy pojawił się nowy commit, czy długie zadanie w tle dobiegło końca), ale to nie jest scheduler działający w tle bez Ciebie.

Hooki i ScheduleWakeup - dlaczego to nie scheduler

Dwa mechanizmy bywają mylone z planowaniem zadań, więc warto je od razu odsiać:

• Hooki - skrypty wpinane w settings.json, które odpalają się na zdarzenia w sesji (przed komendą, po zapisie pliku, na koniec sesji). Są zdarzeniowe, nie czasowe, i działają tylko w trakcie aktywnej sesji. Świetne do lintowania czy auto-commita, bezużyteczne jako scheduler.
• ScheduleWakeup - mechanizm, którym Claude sam ustala, kiedy obudzić się w obrębie trwającej pętli /loop. To element /loop, a nie osobny harmonogram - również wymaga otwartej sesji.

Wniosek: jeśli zadanie ma ruszyć o konkretnej porze albo cyklicznie, niezależnie od tego czy siedzisz przy komputerze - potrzebujesz rutyny.

Rutyny - uruchamianie w chmurze, bez sesji i bez crona

Tu pada odpowiedź na pytanie z początku artykułu. Rutyny (routines) to zaplanowane, zdalne agenty Claude Code. Każda rutyna uruchamia osobną, w pełni izolowaną sesję w chmurze Anthropic - z własnym checkoutem repozytorium z GitHub, własnymi narzędziami i opcjonalnym podłączeniem konektorów. Co kluczowe: rutyna odpali się nawet gdy Twój komputer jest wyłączony, nie wymaga otwartej konsoli i nie korzysta z systemowego crona - harmonogramem zarządza infrastruktura Anthropic.

Jak stworzyć rutynę

Masz dwie drogi. Pierwsza - konwersacyjnie z poziomu Claude Code, komendą /schedule: opisujesz po ludzku co i kiedy ma się dziać, a Claude przekłada to na konfigurację (między innymi przelicza Twoją strefę czasową na UTC).

Druga droga to panel webowy pod adresem claude.ai/code/routines - z formularzem, listą rutyn i gotowymi szablonami (briefing poranny, triage zgłoszeń, health check infrastruktury, przegląd PR-ów i inne).

Po kliknięciu „Nowa rutyna" dostajesz pełen formularz: nazwa, instrukcje dla agenta, wybór repozytorium i środowiska, a poniżej - selektor wyzwalacza i zakładki ustawień (konektory, zachowanie, powiadomienia, uprawnienia).

Trzy typy wyzwalaczy

Jedną rutynę możesz uruchamiać na trzy sposoby - i łączyć je ze sobą:

• Harmonogram (Schedule) - cyklicznie (co godzinę, codziennie, w dni robocze, co tydzień) albo jednorazowo o konkretnej porze. Pod spodem to 5-polowe wyrażenie cron w czasie UTC.
• GitHub event - rutyna rusza na zdarzenie z repozytorium (otwarcie/zamknięcie/aktualizacja PR-a, nowy release), z opcjonalnymi filtrami po autorze, tytule, gałęzi czy etykietach. Wymaga wcześniejszego wskazania repozytorium.
• API - rutynę odpalasz wysyłając żądanie POST z własnego kodu (z tokenem). Idealne, gdy to inny system ma decydować o uruchomieniu - na przykład monitoring, który po wykryciu błędu sam zleca agentowi przygotowanie poprawki.

Przy wyzwalaczu harmonogramowym tryb „Custom" odsłania pole na surowe wyrażenie cron. Warto zwrócić uwagę na jeden szczegół, który łatwo przeoczyć:

Wyrażenie cron jest w UTC, a podsumowanie nad polem - w Twojej strefie. Na zrzucie 0 9 * * * (czyli 9:00 UTC) wyświetla się jako „11:00 CEST", bo latem czas warszawski to UTC+2. To częste źródło pomyłki „rutyna ruszyła dwie godziny za wcześnie" - gdy mówisz Claude'owi „o 9 rano", on sam zrobi konwersję i poprosi o potwierdzenie, ale wpisując cron ręcznie musisz pamiętać o przeliczeniu.

Kilka gotowych wzorców cron (zawsze w UTC):

# minuta godzina dzień-miesiąca miesiąc dzień-tygodnia
0 7 * * 1-5     # w dni robocze o 7:00 UTC (9:00 latem w Polsce)
0 */2 * * *     # co 2 godziny
0 0 * * *       # codziennie o północy UTC
30 14 * * 1     # w każdy poniedziałek o 14:30 UTC
0 8 1 * *       # pierwszego dnia miesiąca o 8:00 UTC

Dla zadania, które ma wykonać się tylko raz w przyszłości, zamiast crona ustawia się jednorazowy termin (run_once_at) - rutyna odpala się o wskazanej porze, a potem sama się wyłącza.

Jak to wygląda w całości

O czym pamiętać przy rutynach

• Minimalny interwał to 1 godzina - wyrażenia częstsze (np. */30 * * * *) są odrzucane.
• Zdalny agent nie ma dostępu do Twojej maszyny - ani do plików lokalnych, ani do lokalnych usług czy zmiennych środowiskowych. Prompt musi być samowystarczalny, bo agent startuje z zerowym kontekstem poza repozytorium i instrukcją.
• Rutyna działa autonomicznie - bez okienek z pytaniami o zgodę. Wszystkie uprawnienia (narzędzia, zakres repozytorium, dostęp sieciowy) definiujesz z góry, więc dobrze przemyśl zakres.
• Działa jako Twój użytkownik - commity i PR-y firmowane są Twoją tożsamością na GitHub.
• Zużycie liczone jest jak zwykła sesja, obowiązuje też dzienny limit uruchomień rutyn.
• Rutyny usuwasz w panelu webowym (przez API nie da się ich skasować).

claude -p z cronem systemowym - rutyna lokalna na Twojej maszynie

Dla porządku: Claude Code potrafi też działać bezwsadowo (headless), w trybie „print". Wpisujesz zadanie jednym poleceniem, agent je wykonuje i kończy działanie:

claude -p "Przejrzyj testy i napraw te, które nie przechodzą" \
  --allowedTools "Read,Bash,Edit" --output-format json

Samo claude -p nie wymaga otwartego okna - uruchamia się i kończy. Ale żeby powtarzać je o stałych porach, to Ty musisz odpalać tę komendę z systemowego crona (Linux/macOS) albo z Harmonogramu zadań (Windows) - a maszyna musi być w tym momencie włączona. Czyli dokładnie ten systemowy cron, którego chcieliśmy uniknąć. W pipeline CI przydaje się flaga --bare (pomija hooki, skille, MCP, automatyczną pamięć i CLAUDE.md - liczą się tylko jawne flagi), co daje powtarzalność.

Przykład: co godzinę sprawdź bazę i wyślij maila - lokalnie

Najczęstsze pytanie brzmi: chcę rutynę, która co godzinę zajrzy do mojej bazy i gdy coś się pojawi - wyśle maila, korzystając z moich lokalnych narzędzi. W chmurze się nie da (zdalny agent nie widzi Twojej bazy ani skryptów). Lokalnie budujesz to z dwóch klocków: promptu claude -p z dostępem do lokalnych narzędzi oraz jednej linijki w cronie.

Najpierw skrypt, który wykonuje właściwą pracę (np. ~/skrypty/dyzur-bazy.sh):

#!/usr/bin/env bash
claude -p "Uruchom zapytanie ./sql/nowe_zamowienia.sql przez psql i sprawdź zamówienia z ostatniej godziny.
Jeśli są nowe - zbuduj krótkie podsumowanie i wyślij je mailem skryptem ./skrypty/wyslij_mail.sh.
Jeśli nic nowego nie ma - nie wysyłaj niczego." \
  --allowedTools "Bash,Read" \
  --output-format json

Potem jedna linijka w crontabie (crontab -e), która uruchamia go o każdej pełnej godzinie:

# min godz dzień mies dz.tyg   polecenie
0 * * * * /home/user/skrypty/dyzur-bazy.sh >> /home/user/log/dyzur.log 2>&1

Teraz Claude Code ma pod ręką lokalny psql, Twoje pliki .sql i skrypt wysyłki maila - czego rutyna w chmurze nigdy nie zobaczy. Cena: to Twój cron pilnuje harmonogramu, a komputer musi być włączony o pełnej godzinie. Klucz API podajesz przez zmienną środowiskową (np. ANTHROPIC_API_KEY w profilu użytkownika crona), nigdy na sztywno w skrypcie.

Kiedy więc po to sięgnąć? Gdy zadanie musi mieć dostęp do Twojego serwera, lokalnych plików, usług albo sieci, których nie ma chmura. W innych przypadkach rutyna w chmurze jest wygodniejsza.

GitHub Actions - Claude Code na harmonogramie w CI

Druga opcja „bez Twojej maszyny i bez Twojego crona": uruchom Claude Code w pipeline GitHub Actions, wyzwalanym harmonogramem. Harmonogramem steruje cron GitHuba, a komenda wykonuje się na runnerze w chmurze GitHuba:

on:
  schedule:
    - cron: '0 7 * * 1-5'   # w dni robocze, 7:00 UTC
jobs:
  claude-task:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: claude -p "Uruchom testy i napraw błędy" --allowedTools "Bash,Read,Edit" --output-format json

To dobry wybór, gdy zadanie jest mocno związane z repozytorium (testy, migracje, porządki w kodzie) i chcesz mieć je obok reszty pipeline CI/CD. Wymaga skonfigurowanego workflow i sekretów (token API), a działanie agenta na GitHub zależy od uprawnień runnera.

Który mechanizm wybrać?

Prosta zasada wyboru: chcesz coś cyklicznego, bez nadzoru i niezależnego od swojego komputera - rutyna w chmurze. Pilnujesz czegoś w trakcie sesji - /loop. Zadanie potrzebuje Twojego serwera i lokalnych zasobów - claude -p z cronem. Chcesz to trzymać w pipeline repozytorium - GitHub Actions.

Na szkoleniu pokazujemy na żywo automatyzacje, rutyny, hooki i pracę z wieloma agentami - na realnych projektach, z praktykiem JSystems. Zobacz szczegóły i terminy gwarantowane szkolenia Claude Code.

Podsumowanie

Wracając do pytania z początku: tak - Claude Code potrafi uruchamiać zadania automatycznie w tle, bez otwartej konsoli i bez systemowego crona. Służą do tego rutyny biegnące w chmurze Anthropic (na razie w statusie research preview). Jeśli zadanie ma żyć tylko w trakcie Twojej sesji - wystarczy /loop. Jeśli musi mieć dostęp do lokalnej maszyny - zostaje claude -p z cronem systemowym. A gdy chcesz trzymać automat blisko kodu - GitHub Actions na harmonogramie. Cztery narzędzia, cztery różne odpowiedzi na „odpal to za mnie".

×