>_ DevTrendspl

Język

Strona główna

Języki

Sekcje

Frontend Backend Mobilne DevOps AI / ML GameDev Blockchain Systemy wbudowane Bezpieczeństwo
Rust

Jak przestałem bać się Claude Code i nauczyłem się kochać strażniki

Wyobraź sobie: siedzisz wygodnie w fotelu, popijasz kawę, podczas gdy Twój ulubiony agent AI (czy to Claude Code, Cursor czy GitHub Copilot CLI) radośnie donosi o zakończeniu zadania refaktoryzacji. Nagle w terminalu pojawia się rm -rf, a jeszcze zabawniej — sudo rm -rf /. Kawa utknie Ci w gardle, a godziny niezapłaconej pracy — te zmiany, których jeszcze nie commitowałeś — wyparują w cyfrową otchłań.

Znane uczucie bezradności wobec „halucynacji" sieci neuronowej? W mojej praktyce takie momenty zdarzały się kilka razy, a za każdym razem była to bolesna lekcja. Dlatego projekt destructive_command_guard (lub po prostu dcg) od razu przykuł moją uwagę. To nie jest „rewolucyjna platforma", po prostu bardzo szybki i śmiały piesek stróżujący dla Twojego terminala.

Co to za bestia

Krótko mówiąc, dcg to wysokowydajny hook napisany w Rust. Przechwytuje proces komunikacji między Tobą (lub Twoim agentem AI) a linią poleceń. Jego jedyne zadanie to przechwycić destrukcyjne polecenie zanim zdąży coś zepsuć.

Narzędzie obsługuje praktycznie wszystko, co jest obecnie na topie w świecie programowania z AI: Claude Code, Codex CLI, Gemini CLI, Copilot CLI, Cursor IDE, Grok, a nawet egzotyczne opcje jak Hermes Agent. Narzędzie działa na Linuksie, macOS i Windows (przez WSL lub natywnie przez PowerShell).

Dlaczego zwykły grep Cię nie uratuje

Może się wydawać: po co budować cały projekt w Rust, skoro można napisać prosty skrypt w Bashu lub Pythonie? Autor projektu, Jeffrey Emanuel, poszedł tą drogą: pierwsza wersja była w Pythonie. Ale szybko stało się jasne, że współczesne zadania wymagają bardziej nuansowanego podejścia.

Kontekst jest wszystkim

dcg nie wyszukuje po prostu ciągu znaków rm -rf. Analizuje kontekst. Jeśli agent napisze „nie używaj rm -rf /" w dokumentacji, hook zrozumie, że to są dane i nie zablokuje zapisu do pliku. Ale gdy tylko dojdzie do faktycznego wykonania polecenia — blokada wchodzi w życie.

Do tego używany jest trójpoziomowy system weryfikacji:

  1. Szybkie wyszukiwanie podciągów (Quick Reject) za pomocą instrukcji SIMD. Trwa to mikrosekundy.
  2. Normalizacja poleceń (usuwanie dodatkowych spacji, zastępowanie ścieżek bezwzględnych względnymi).
  3. Sprawdzanie względem złożonych wzorców przy użyciu wyrażeń regularnych.

Ochrona przed „ukrytymi" zagrożeniami

Ciekawa funkcja — skanowanie Heredocs i skryptów inline. Jeśli agent zdecyduje się wywołać rm -rf, prosty filtr linii poleceń przepuści to. dcg zagłębia się w takie konstrukcje, parsuje je za pomocą AST (Abstract Syntax Trees) i znajduje podejrzane wywołania funkcji.

Co dokładnie blokuje

Out of the box, nawet jeśli nic nie skonfigurowałeś, dcg chroni przed najstraszniejszymi rzeczami:

  • rm -rf, sudo rm -rf /, dd if=/dev/zero.
  • git push --force poza folderami tymczasowymi.
  • Formatowanie dysku, usuwanie partycji i inne systemowe radości.

Ale najlepsze jest to, że są „pakiety" (pakiety bezpieczeństwa). W repozytorium jest ich ponad 50. Możesz aktywować ochronę dla konkretnych technologii w swoim dcg.toml:

[packs]
enabled = [
    "database.postgresql",    # Заблокирует DROP TABLE
    "kubernetes.kubectl",     # Не даст удалить namespace по ошибке
    "cloud.aws",              # Спасет от случайного terminate-instances
    "containers.docker",      # Ограничит docker system prune
]

Jak to wygląda w praktyce

Powiedzmy, że Twój agent postanowił zgłupieć i zresetować wszystkie zmiany. Zobaczysz coś takiego w terminalu:

════════════════════════════════════════════════════════════════
BLOCKED  dcg
────────────────────────────────────────────────────────────────
Reason:  git reset --hard destroys uncommitted changes

Command: git reset --hard HEAD~5

Tip: Consider using 'git stash' first to save your changes.
════════════════════════════════════════════════════════════════

Blokada zawiera pomocne porady. W większości przypadków agent, otrzymawszy takie odrzucenie, uświadamia sobie błąd i sugeruje bezpieczniejszą ścieżkę, na przykład używając git stash.

Techniczne wnętrzności i wydajność

To, co mnie przekonało, to podejście do wydajności. Autor twierdzi o opóźnieniach poniżej milisekundy. Dla lubiących szczegóły:

  • Rust + SIMD: wektorowe instrukcje procesora są używane do błyskawicznego wyszukiwania słów kluczowych.
  • Podwójny silnik wyrażeń regularnych: proste wzorce obsługuje szybki silnik z liniowym czasem wykonania, podczas gdy złożone (gdzie potrzebne są lookahead/lookbehind) przetwarza mocniejszy, ale wolniejszy regex.
  • Zero-alokacji: na gorących ścieżkach program stara się nie alokować pamięci sterty, co jest krytyczne, gdy hook jest wywoływany przy każdym naciśnięciu klawisza lub poleceniu agenta.

Przy okazji, projekt implementuje filozofię fail-open. Jeśli dcg nie zdąży przeanalizować polecenia w wyznaczonym budżecie czasowym (domyślnie 200 ms), przepuszcza je. Robi się to po to, by narzędzie nigdy nie stało się „hamulcem" utrudniającym normalną pracę. Moim zdaniem rozsądny kompromis między bezpieczeństwem a wygodą.

Jak zintegrować z własnym workflow

Najłatwiejszy sposób, żeby wypróbować, to uruchomić skrypt instalacyjny z README. Określi on Twój system operacyjny, pobierze odpowiednie binarium i skonfiguruje ustawienia w konfiguracjach agentów AI.

Dla Claude Code wygląda to jak dodanie sekcji do claude_desktop_config.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "dcg" }]
      }
    ]
  }
}

A jeśli pracujesz w zespole i chcesz upewnić się, że nikt nie commitował destrukcyjnego git push --force czy zepsutego pipeline'u CI, jest tryb skanowania:

dcg scan --staged

Możesz podpiąć to pod pre-commit hook, a sprawdzi wszystkie pliki, które próbujesz wysłać do Git.

Kilka słów o minusach

Nie ma idealnych narzędzi. Co może pójść nie tak?

  1. Fałszywe pozytywy: Pomimo zaawansowanego parsowania, czasami dcg może zablokować całkowicie legalne polecenia. Na ten przypadek jest „awaryjne wyjście" przez zmienną środowiskową DCG_BYPASS lub system DCG_UNLOCK_CODE.
  2. Złożoność konfiguracji: Jeśli potrzebujesz czegoś specyficznego, musisz zagłębić się w konfiguracje TOML.
  3. Rust Nightly: Jeśli chcesz zbudować projekt ze źródeł samodzielnie, potrzebujesz wersji nightly Rust, ponieważ używane są funkcje z edycji 2024.

Kto tego potrzebuje

Jeśli używasz agentów AI więcej niż raz w tygodniu i powierzasz im wykonywanie poleceń w terminalu — instaluj bez wahania. To tanie ubezpieczenie. Szczególnie istotne dla początkujących, którzy mogą nie od razu zauważyć, że „polecenie czyszczenia cache" zasugerowane przez sieć neuronową w rzeczywistości wymazuje połowę systemu.

Dla doświadczonych programistów to bardziej sposób na oszczędzenie nerwów. Wszyscy wiemy, jak łatwo wcisnąć Ctrl+C na autopilocie, a potem gorączkowo przypominać sobie, kiedy była ostatnia kopia zapasowa.

Destructive Command Guard - Protecting your code from accidental destruction

dcg to właśnie to narzędzie, które cicho działa w tle i „nie prosi o jedzenie", dopóki nie nadejdzie krytyczny moment. Nie robi magii, po prostu dobrze parsuje ciągi znaków i wie, jak wyglądają złe polecenia. W świecie, w którym coraz częściej delegujemy pisanie i wykonywanie kodu na maszyny, takie „cyfrowe bezpieczniki" stają się obowiązkowym atrybutem środowiska pracy.

Warto wypróbować przynajmniej po to, żeby zobaczyć, jak szybkie jest współczesne oprogramowanie w Rust. A czy Ty kiedykolwiek powierzyłeś swojemu AI usuwanie plików? Jak to się skończyło?

Powiązane projekty