Uprawnienia, sandboksy i tryby zatwierdzania w Claude Code, Codex i Cursorze

Uprawnienia i sandboksy w Claude Code, Codex i Cursorze to trzy osobne mechanizmy: warstwa zatwierdzania decyduje, czy akcja się wykona, sandboks systemowy ogranicza, co polecenie powłoki może czytać i zapisywać, a lista dozwolonych hostów ogranicza, z czym to polecenie może się połączyć. Praca bez nadzoru jest bezpieczna dopiero wtedy, gdy ustawione są wszystkie trzy, a nie sama warstwa zatwierdzania.

Agent poprosił o zgodę czterdzieści razy podczas jednego refaktoringu, więc ktoś dodał flagę obejścia „tylko na dziś”. Dwa tygodnie później flaga siedzi w jobie CI, który triażuje publiczne zgłoszenia, runner trzyma token do publikacji paczki w npm, a nikt nie potrafi powiedzieć, która granica zatrzymałaby wstrzyknięty curl. Ta strona jest dla developera, który konfiguruje sesję, dla tech leada, który odpowiada za wspólne ustawienia, i dla CTO, który podpisuje się pod tym, do czego agenci bez nadzoru mają dostęp. To krok 4 ścieżki developera, po kontekście repozytorium, bo każdy kolejny krok, od worktree po potok od zgłoszenia do PR, zakłada, że te granice już istnieją.

Co daje ci to zestawienie uprawnień

• Macierz mechanizmów zatwierdzania, sandboksa, sieci i poświadczeń w Claude Code v2.1.283, Codex CLI 0.157.1 i Cursorze.
• Tabelę ustawień dla każdej klasy ryzyka i typu uruchomienia (interaktywne, w tle, CI).
• Konfigurację do zacommitowania dla wszystkich trzech narzędzi, w tym job GitHub Actions z Codex.
• Test kanarkowy, który dowodzi, że granica trzyma, zamiast ufać plikowi ustawień.
• Trzy prompty do skopiowania i typowe awarie ze sposobami wyjścia.

Jakich trzech warstw potrzebuje każde uruchomienie agenta?

Dostawcy różnie nazywają odpowiedzi na te same trzy pytania. Mocna odpowiedź na jedno nie zastępuje pozostałych.

Warstwa	Na jakie pytanie odpowiada	Claude Code	Codex	Cursor
Zatwierdzanie	Czy ta akcja się wykona i kto mówi „tak”?	Tryby uprawnień i reguły allow/ask/deny	Polityka zatwierdzania i auto-review	Run modes i Auto-review
Sandboks systemowy	Co uruchomione polecenie może czytać i zapisywać?	Sandboksowane narzędzie Bash	Sandboks albo profil uprawnień	Sandboks dla poleceń powłoki
Ruch wychodzący	Z czym uruchomione polecenie może się połączyć?	Proxy sandboksa z listą dozwolonych domen	Ustawienie sieci w profilu	Niezweryfikowane (niżej)

Warstwa zatwierdzania ocenia tekst polecenia, zanim się uruchomi. Sandboks egzekwuje system operacyjny na działającym procesie. Przewodnik Anthropic po sandboksie ujmuje tę różnicę wprost: granica sandboksa „holds regardless of what the model chose to run and even if an allowed command does more than its name suggests”. Reguła deny na Bash(curl *) zatrzyma curl, ale nie python -c, który sam otworzy gniazdo sieciowe; sandboks zatrzyma oba.

Poza tymi trzema warstwami leży granica zewnętrzna: laptop, kontener, maszyna wirtualna albo środowisko chmurowe, w którym działa agent, razem z jego poświadczeniami. Jej wybór opisują środowiska efemeryczne, a katalog narzędzi porównanie sandboksów dla agentów.

Jak Claude Code, Codex i Cursor wypadają w porównaniu uprawnień i sandboksów?

Sprawdzone 2026-09-26 na claude --help 2.1.283 oraz dokumentacji Anthropic o uprawnieniach, sandboksie i środowiskach chmurowych; na codex --help 0.157.1, kodzie źródłowym z tagu rust-v0.157.1 i README openai/codex-action; oraz na paczce @cursor/sdk 1.0.32. Dokumentacja Cursora była tego dnia nieosiągalna z naszego środowiska, więc kolumna Cursora zawiera tylko to, co potwierdza paczka SDK albo sprawdzenie dokumentacji z 2026-08-28.

Mechanizm	Claude Code 2.1.283	Codex CLI 0.157.1	Cursor
Tryby zatwierdzania	default (widoczny jako Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions; przełączanie Shift+Tab	approval_policy: untrusted, on-request (domyślny), granular, never. Flaga -a przyjmuje tylko on-request i never	Strona Run modes w sekcji Agent security; zgłaszane tryby to Auto-review (domyślny), Allowlist i Run Everything (niezweryfikowane, 2026-09-26)
Model zatwierdza zamiast ciebie	Tryb auto: klasyfikator (domyślnie Claude Sonnet 5) ocenia akcje. Od v2.1.283 (kanał latest) to tryb startowy sesji interaktywnych	Auto-review: approvals_reviewer = "auto_review" w konfiguracji albo --approve-for-me	Auto-review (opcja SDK local.autoReview)
Reguły poleceń	permissions.allow, ask, deny, sprawdzane w kolejności deny, ask, allow	Pliki .rules (eksperymentalne) decydują, które polecenia mogą działać poza sandboksem	Hooki: JSON przez stdio, które „can observe, block, or modify behavior”
Sandboks systemowy	Polecenia Bash, PowerShell i Monitor. macOS Seatbelt, Linux i WSL2 bubblewrap; natywny Windows nieobsługiwany	Każde polecenie powłoki wygenerowane przez model. macOS Seatbelt, Linux i WSL2 bubblewrap; WSL1 odrzucany	local.sandboxOptions w SDK; /sandbox na liście poleceń CLI
Domyślna granica zapisu	Katalog roboczy, katalog tymczasowy użytkownika i katalogi dodane przez --add-dir	Profil :workspace zapisuje w katalogu roboczym; :read-only nie zapisuje nic	Niezweryfikowane
Domyślna sieć	Żadna domena nie jest dozwolona z góry; pierwsze użycie hosta wywołuje pytanie albo, w trybie auto, trafia do klasyfikatora	:workspace „does not grant network access” (README codex-action; potwierdzone lokalnie, patrz test kanarkowy)	Niezweryfikowane
Lista dozwolonych hostów	sandbox.network.allowedDomains, deniedDomains, strictAllowlist, zarządzane allowManagedDomainsOnly	Nazwane profile [permissions] mają reguły allow i deny per domena (beta); starsze network_access działa na zasadzie wszystko albo nic	Niezweryfikowane
Sekrety w środowisku	sandbox.credentials: deny albo mask dla plików i zmiennych; domyślnie nic nie jest chronione	shell_environment_policy: ignore_default_excludes ma domyślnie true, więc zmienne *KEY*, *SECRET*, *TOKEN* trafiają do poleceń, dopóki nie ustawisz false	Niezweryfikowane
Pełne obejście	--dangerously-skip-permissions; odmowa pod rootem albo sudo poza rozpoznanym sandboksem	--dangerously-bypass-approvals-and-sandbox	Niezweryfikowane
Blokada administratora	Ustawienia zarządzane: disableBypassPermissionsMode, disableAutoMode, sandbox.failIfUnavailable, allowManagedDomainsOnly	requirements.toml: allowed_approval_policies, allowed_approvals_reviewers, allowed_permission_profiles, experimental_network, rules (sprawdzone w config_requirements.rs z tagu rust-v0.157.1)	Warstwa ustawień mdm (settingSources w SDK)

Uwagi: sandboks Claude Code obejmuje tylko polecenia powłoki; narzędzia Read, Edit i Write podlegają regułom uprawnień, nie sandboksowi. Profile uprawnień Codex (beta, od 0.138.0) i starsze wartości --sandbox „do not compose”, więc w jednej konfiguracji wybierz jedno z nich.

Jakie ustawienia pasują do klasy ryzyka i typu uruchomienia?

Klasa ryzyka należy do zmiany, nie do zespołu. Uruchomienie dostaje ustawienia najwyższej klasy, jakiej może dotknąć: zadanie „tylko dokumentacja” w repozytorium z kodem rozliczeń działa z ustawieniami rozliczeń, chyba że sandboks odcina mu te ścieżki. Tech lead odpowiada za tę tabelę w każdym repozytorium; CTO albo właściciel bezpieczeństwa podpisuje wiersz krytyczny i każdy wyjątek.

Klasa ryzyka	Warstwa zatwierdzania	System plików	Sieć	Poświadczenia w środowisku
Niska (dokumentacja, narzędzia wewnętrzne)	Model recenzujący (tryb auto, auto-review)	Zapis w katalogu roboczym	Tylko rejestry paczek	Nic poza tokenem repozytorium tylko do odczytu
Średnia (logika funkcji za flagą)	Model recenzujący plus reguły ask na git push i zmiany zależności	Zapis w katalogu roboczym, odczyt ścieżek z sekretami zablokowany	Rejestry plus nazwane hosty wewnętrzne, ścisła lista	Zamaskowane albo brak
Wysoka (publiczne API, testy, konfiguracja CI)	Model recenzujący dla kodu; reguły ask na .github/, ścieżki testów i konfiguracji CI	Zapis w katalogu roboczym; edycja konfiguracji CI wymaga zgody	Ścisła lista, bez symboli wieloznacznych (wildcardów) dla hostów, które przyjmują przesyłane pliki	Brak
Krytyczna (uwierzytelnianie, pieniądze, migracje, sekrety, sam harness)	Tryb Manual albo plan; nigdy obejście	Zapis w katalogu roboczym wewnątrz jednorazowego kontenera albo VM	Żadnego ruchu poza mirrorem rejestru	Nigdy żadnych produkcyjnych poświadczeń

W uruchomieniu w tle albo w CI nikt nie odpowie na pytanie, więc typ uruchomienia ogranicza wybór warstwy zatwierdzania:

Typ uruchomienia	Warstwa zatwierdzania, która działa	Co zastępuje człowieka	Granica zewnętrzna
Interaktywne	Dowolny tryb; tryb auto albo auto-review przy długich zadaniach	Ty, przy pytaniach, które zostały	Twój laptop, więc cały ciężar niesie sandboks
W tle albo w chmurze	Model recenzujący; obejście tylko w jednorazowej VM albo kontenerze	Klasyfikator lub recenzent plus poziom sieci środowiska chmurowego	VM dostawcy albo twój własny runner
CI	Dokładna lista dozwolonych narzędzi (dontAsk) albo never z profilem	Sama lista: wszystko spoza niej jest odrzucane	Jednorazowy runner z wąsko ograniczonymi tokenami

Model recenzujący to nie sandboks

Tryb auto w Claude Code i auto-review w Codex oceniają intencję; nie zamykają procesu w klatce. Anthropic podaje, że tryb auto nie wymaga izolacji, ale „a sandbox or container adds defense in depth”. Od klasy średniej wzwyż uruchamiaj recenzenta wewnątrz sandboksa systemowego, a nie zamiast niego.

Skonfiguruj ustawienia sesji interaktywnej

Zacommituj bazowe ustawienia zespołu do repozytorium, a elementy nienegocjowalne przenieś do ustawień zarządzanych, których użytkownik nie nadpisze. Dystrybucję jednej polityki na wszystkie narzędzia opisuje polityka zarządzana.

Claude Code

Bazowe ustawienia projektu w .claude/settings.json (klasa średnia): sandboks włączony, bez ponawiania poza sandboksem, ograniczony ruch wychodzący, dwa tokeny zabrane poleceniom w sandboksie i pytanie przy pushu i edycji CI:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Bash(terraform apply *)"],
    "ask": ["Bash(git push *)", "Edit(/.github/**)"]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["registry.npmjs.org", "github.com", "api.github.com", "codeload.github.com"]
    },
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "NPM_TOKEN", "mode": "deny" },
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Ustawienia zarządzane dla organizacji, dostarczane przez MDM albo z serwera, trzymają klucze, których sklonowane repozytorium nie może ustawić ani poluzować:

{
  "permissions": { "disableBypassPermissionsMode": "disable" },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": { "strictAllowlist": true, "allowManagedDomainsOnly": true }
  }
}

• Lista wymienia konkretne hosty GitHuba zamiast *.github.com, bo symbol wieloznaczny pasowałby też do gist.github.com i uploads.github.com, czyli miejsc, do których wstrzyknięte polecenie mogłoby wysłać dane.
• Ustawienia projektu nie uruchomią sesji w trybie auto ani bypassPermissions; te wartości są tam ignorowane. Tryb startowy ustaw w ustawieniach użytkownika albo zarządzanych.
• strictAllowlist odrzuca hosty spoza listy zamiast pytać i nie działa w plikach ustawień repozytorium. Wymaga v2.1.219 lub nowszej.
• Na Linuksie i WSL2 najpierw zainstaluj bubblewrap i socat. Uruchom /sandbox w sesji: jeśli widzisz tylko zakładkę Dependencies, sandboks nie działa.
• /permissions pokazuje każdą aktywną regułę i plik, z którego pochodzi, oraz ostatnie odmowy trybu auto.

Codex

Plik config.toml użytkownika albo projektu (klasa średnia). Wbudowany profil :workspace zapisuje tylko w katalogu roboczym i nie daje dostępu do sieci. Ustawienie ignore_default_excludes = false usuwa z poleceń powłoki zmienne o nazwach wyglądających na klucze, sekrety i tokeny:

default_permissions = ":workspace"
approval_policy = "on-request"
approvals_reviewer = "auto_review"   # eskalacje rozstrzyga agent recenzujący; domyślnie "user"

[shell_environment_policy]
ignore_default_excludes = false

Ograniczenia administratora trafiają do requirements.toml, którego użytkownik nie nadpisze. Jego klucze nie są nazwami z config.toml: plik przyjmuje między innymi allowed_approval_policies, allowed_approvals_reviewers, allowed_permission_profiles, experimental_network i rules (sprawdzone w config_requirements.rs z tagu rust-v0.157.1). Wpis approval_policy = "never" niczego tam nie ogranicza.

• Nie dodawaj sandbox_mode ani --sandbox do konfiguracji, która używa default_permissions; te dwa systemy się nie składają.
• /permissions w TUI pokazuje i zmienia to, co Codex może robić; /approve ponawia jedną odmowę auto-review.
• Gdy zadanie potrzebuje rejestru paczek, zainstaluj zależności wcześniej albo zdefiniuj nazwany profil [permissions] z regułami sieci per domena (beta; sprawdź schemat w kodzie źródłowym Codex).

Cursor

Cursor opisuje zachowanie zatwierdzania i sandboksa na stronie Run modes w sekcji Agent security. 2026-09-26 nie mieliśmy dostępu do cursor.com, by sprawdzić aktualne nazwy trybów i wartości domyślne; odczytaj je w swojej wersji, zanim ustalisz standard zespołu. Zweryfikowane:

• Auto-review istnieje dla lokalnych wywołań narzędzi, a SDK udostępnia je jako local.autoReview.
• Sandboks można włączyć per uruchomienie przez SDK (local.sandboxOptions), a /sandbox jest na liście poleceń slash w Cursor CLI.
• Hooki „can observe, block, or modify behavior”. Wersjonuj w repozytorium hook, który blokuje polecenia powłoki sięgające do niedozwolonych hostów albo ścieżek z sekretami; nazwy zdarzeń weź ze strony Cursora o hookach.
• Cloud Agents „run in isolated VMs in the cloud”, co przenosi zasięg szkód z laptopa developera.

Wybierz najbardziej restrykcyjny run mode, z którym zespół może pracować, włącz sandboks i uruchom test kanarkowy opisany niżej, żeby zobaczyć, co blokuje.

Skonfiguruj uruchomienia w tle i w chmurze

Uruchomienie w tle nie odpowie na pytanie, więc warstwa zatwierdzania decyduje sama, a poziom sieci środowiska staje się główną kontrolą ruchu wychodzącego.

Claude Code

• Sesje chmurowe (claude.ai/code, routines) mają poziom Network access: None, Trusted (rejestry paczek, GitHub i SDK chmurowe; domyślny), Full albo Custom. Ruch do GitHuba, włączone konektory MCP i API Anthropic go omijają, więc wyłącz konektory, których zadanie nie potrzebuje.
• Sesje chmurowe ignorują defaultMode: "bypassPermissions" i "dontAsk" z plików ustawień, więc repozytorium nie uruchomi takiej sesji w trybie obejścia.
• Lokalne sesje w tle uruchamiane z --bg są odrzucane w trybie obejścia, dopóki raz nie zaakceptujesz ostrzeżenia w sesji interaktywnej. W sesjach w tle ścisły tryb sandboksa obejmuje też polecenia wpisane po !.

Codex

• codex exec działa nieinteraktywnie z tymi samymi ustawieniami profilu i zatwierdzania co TUI. Flagę -a podaj przed podpoleceniem: codex -a never exec …; w 0.157.1 codex exec nie ma własnego -a.
• Zadania w Codex cloud działają „in isolated cloud environments” konfigurowanych per środowisko (dokumentacja OpenAI, sprawdzona 2026-08-28). Ustawienie sieci środowiska to kontrola ruchu wychodzącego; sprawdź je, zanim podłączysz repozytorium z poświadczeniami do wdrożeń.

Cursor

• Cloud Agents działają w izolowanych VM; daj każdej VM własne, wąsko ograniczone poświadczenia, nigdy osobisty token.
• Przy lokalnych uruchomieniach sterowanych z kodu SDK czyni ustawienia jawnymi. Gdy włączone jest autoReview albo sandboks, wywołania narzędzi serwerów MCP, które wymagałyby interaktywnej zgody, „fail closed”:

run-agent.mjs

import { Agent } from '@cursor/sdk';

const MODEL_ID = process.env.CURSOR_MODEL_ID; // identyfikator z Cursor.models.list()

const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY,
  model: { id: MODEL_ID }, // wybierz z Cursor.models.list()
  tools: ['read', 'grep', 'glob', 'edit', 'shell'],
  local: {
    cwd: process.cwd(),
    autoReview: true,
    sandboxOptions: { enabled: true },
    settingSources: ['project', 'team', 'mdm'],
  },
});

const run = await agent.send('Run the unit tests and fix the failing test in src/billing.');
const result = await run.wait();
console.log(result.status); // 'finished', 'error' or 'cancelled'
if (result.status !== 'finished') process.exit(1);

CURSOR_MODEL_ID zawiera identyfikator modelu z Cursor.models.list(); SDK wymaga go dla lokalnych agentów. result.status przyjmuje wartość finished, error albo cancelled. Sprawdzone na @cursor/sdk 1.0.32.

Skonfiguruj uruchomienia w CI

W CI agent styka się z niezaufanym tekstem: tytułami zgłoszeń, opisami pull requestów i diffami z forków. Daj jobowi dokładną listę dozwolonych narzędzi, sandboks ograniczony do katalogu roboczego i token ograniczony do jego jednego zadania. Utwardzanie GitHub Actions (pull_request_target, uprawnienia tokenów, OIDC) opisuje strona tożsamość agentów, poświadczenia i sekrety.

Claude Code

dontAsk odrzuca wszystko, co wymagałoby pytania, więc lista dozwolonych narzędzi jest całą polityką. --permission-prompts none gwarantuje, że nic nie czeka na odpowiedź. --settings włącza sandboks dla tego uruchomienia i zabrania ponowienia polecenia poza nim, a reguła --disallowedTools trzyma testy, czyli wyrocznię, poza zasięgiem Edit (dopasuj /tests/** do układu repozytorium, w tej samej postaci ścieżki co pozostałe reguły na tej stronie):

# CI: uruchom i napraw testy, nic więcej
claude -p "Run the test suite and fix failing tests in src/. Do not edit tests." \
  --permission-mode dontAsk \
  --permission-prompts none \
  --settings '{"sandbox":{"enabled":true,"allowUnsandboxedCommands":false}}' \
  --allowedTools "Read" "Edit" "Bash(npm test)" "Bash(npm run lint)" \
  --disallowedTools "Edit(/tests/**)"

Sesje claude -p startują w trybie Manual, więc akcje spoza listy są odrzucane nawet bez --permission-mode. Przy jobie triażu tylko do odczytu --restricted usuwa narzędzia uruchamiające polecenia i WebFetch, chyba że wymieni je --tools, i odmawia bypassPermissions.

Codex

README openai/codex-action zaleca profil uprawnień zamiast starszych flag sandboksa, a domyślne safety-strategy: drop-sudo odbiera użytkownikowi runnera sudo, zanim wystartuje Codex:

- name: Run Codex
  uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    permission-profile: ":workspace"
    safety-strategy: drop-sudo
    prompt: |
      Run the unit tests and fix failing tests in src/. Do not edit tests.

Zainstaluj zależności we wcześniejszym kroku: :workspace nie daje dostępu do sieci. Podanie jednocześnie permission-profile i sandbox kończy się błędem, zanim Codex wystartuje. Windowsowe runnery hostowane przez GitHub wymagają safety-strategy: unsafe, więc trzymaj joby agentów na Linuksie albo macOS. Z gołej powłoki:

codex -a never exec -c 'default_permissions=":workspace"' \
  "Run the unit tests and fix failing tests in src/. Do not edit tests."

Cursor

Zweryfikowana droga to skrypt SDK z sekcji wyżej, zapisany jako run-agent.mjs i uruchamiany w kroku CI. Wcześniejszy krok instaluje @cursor/sdk, klucz pochodzi z sekretu, a identyfikator modelu ze zmiennej repozytorium:

- run: npm install @cursor/sdk@1.0.32
- name: Run Cursor agent
  run: node run-agent.mjs
  env:
    CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
    CURSOR_MODEL_ID: ${{ vars.CURSOR_MODEL_ID }}

Skrypt zostawia sandboxOptions: { enabled: true } i kończy się kodem niezerowym, gdy uruchomienie się nie powiedzie. Cursor opisuje też tryb headless print CLI (-p, --print) dla GitHub Actions (sprawdzone 2026-08-28), ale jego flag uprawnień nie dało się tu zweryfikować. Uruchom job na jednorazowym runnerze z Linuksem i tokenem ograniczonym do repozytorium, a zanim job zobaczy publiczne dane wejściowe, udowodnij granicę testem kanarkowym. Konfigurację CI dla wszystkich narzędzi porównuje strona agenci headless w CI.

Jak udowodnić, że granica sandboksa trzyma?

Plik ustawień to deklaracja. Test kanarkowy to dowód: polecenie, które przy danej polityce musi się nie udać, uruchomione tak, jak uruchamia je agent. Uruchom go przy ustawianiu polityki, przy każdej zmianie ustawień harnessu i po każdej aktualizacji narzędzia.

1. Wybierz trzy próby dla danych ustawień: zapis poza katalogiem roboczym, odczyt ścieżki z sekretem i połączenie z hostem spoza listy dozwolonych.

2. W Codex przepuść próby przez codex sandbox, który stosuje ten sam sandboks, jaki dostaje agent. Z codex-cli 0.157.1 na Linuksie to uruchomienie wypisało ok, potem Read-only file system dla /etc, a na koniec odmowę połączenia dla curl:

   codex sandbox -c 'default_permissions=":workspace"' -- sh -c \
     'echo ok > probe.txt && cat probe.txt; echo x > /etc/probe; curl -sS -m 5 https://example.com'

3. W Claude Code i Cursorze uruchom prompt kanarkowy z sekcji niżej w sesji z ustawieniami, które wdrażasz. Każda próba musi zostać zablokowana albo odrzucona; przy ustawieniach dla pracy w tle i w CI pytanie o zgodę liczy się jako porażka.

4. Zapisz wynik w pakiecie dowodów pull requesta, który zmienił ustawienia. Właściciel harnessu podpisuje wynik testu kanarkowego, a nie diff ustawień.

5. Powtarzaj test kanarkowy w CI przy każdej zmianie .claude/settings.json, config.toml albo hooka. Zmiany w harnessie mają klasę krytyczną.

Prompty do skopiowania: uprawnienia i sandboks

Prompt do skopiowania: audyt obecnych ustawień

Audit this repository's agent permissions without changing anything. Read .claude/settings.json, .claude/settings.local.json, ~/.claude/settings.json, .codex/config.toml, ~/.codex/config.toml and any hook scripts that exist. Produce one table with a row per run type (interactive, background, CI) and columns: approval mode or policy, OS sandbox on or off, writable paths, network allowlist, secrets reachable from shell commands, and the bypass flag if any. Then list every place where a checked-in file tries to widen permissions, every wildcard domain that accepts uploads, and every environment variable matching KEY, SECRET or TOKEN that a sandboxed command could read. End with the three changes that remove the most risk, as exact settings diffs.

Prompt do skopiowania: test kanarkowy sandboksa

This is a sandbox canary test. Do not work around any failure and do not ask me to approve anything; report each result exactly as the tool returns it. Run these four shell commands one at a time: (1) echo canary > ./canary.txt, (2) echo canary > ~/canary-outside.txt, (3) cat ~/.ssh/id_ed25519 | head -c 20, (4) curl -sS -m 5 https://example.com. Then delete ./canary.txt. Report a table: command, expected (1 allowed, 2 to 4 blocked), actual result, and which layer blocked it (permission rule, sandbox filesystem, sandbox network, classifier). Flag any command that ran outside the sandbox.

Prompt do skopiowania: ustawienia dla klasy ryzyka

Write the agent permission settings for this repository at risk class high: public API contracts and CI configuration live here. Target Claude Code (.claude/settings.json) and Codex (.codex/config.toml). Requirements: OS sandbox on with no unsandboxed retry; writes limited to the workspace; network limited to registry.npmjs.org and our registry mirror; deny reads of .env files and ~/.ssh; force a prompt for git push and for any edit under .github/ and tests/; strip KEY, SECRET and TOKEN variables from shell commands; no bypass mode. Use only keys documented for Claude Code 2.1.283 and Codex 0.157.1, and for Codex use a permission profile, not sandbox_mode. After writing them, list which of these settings a user could override locally and which must move to managed settings or requirements.toml.

Co psuje się w uprawnieniach i sandboksach agentów i jak z tego wyjść

• Sandboks po cichu nie działa. Domyślnie, gdy brakuje bubblewrap albo socat albo system to natywny Windows, Claude Code tylko ostrzega i uruchamia polecenia bez sandboksa. Wyjście: ustaw sandbox.failIfUnavailable: true w ustawieniach zarządzanych, a na Ubuntu 24.04 i nowszym dodaj profil AppArmor dla bwrap z przewodnika Anthropic po sandboksie.
• Agent ponawia polecenie poza sandboksem. Claude Code może powtórzyć zablokowane polecenie z dangerouslyDisableSandbox; przechodzi ono zwykłe zatwierdzanie, więc w trybie auto klasyfikator może je przepuścić. Wyjście: allowUnsandboxedCommands: false albo reguła ask na Bash(dangerouslyDisableSandbox:true).
• Reguła deny omijana inną pisownią. Bash(curl *) nie pasuje do sh -c 'curl …'. Wyjście: traktuj reguły poleceń jako pierwsze sito; kontrolą ruchu wychodzącego jest lista dozwolonych hostów.
• Ustawienia projektu, które nic nie robią. auto albo bypassPermissions jako defaultMode, strictAllowlist, wpisy mask dla poświadczeń i filesystem.disabled są ignorowane w ustawieniach .claude/ repozytorium. Wyjście: przenieś je do ustawień użytkownika albo zarządzanych.
• Dozwolony host służy za wyjście. Symbol wieloznaczny na hoście, który przyjmuje przesyłane pliki albo gisty, pozwala wstrzykniętemu poleceniu wysłać dane przez zatwierdzoną domenę; wśród advisory samego Claude Code jest wyciek przez dozwoloną z góry domenę HuggingFace w WebFetch (Moderate, 2026-06-13); ten sam wzorzec dotyczy każdego dozwolonego hosta przyjmującego przesyłane pliki. Wyjście: dopuszczaj konkretne hosty, preferuj mirror rejestru i wpisz endpointy przesyłania plików do deniedDomains.
• Sekrety jadą razem ze środowiskiem. Codex przekazuje poleceniom zmienne *TOKEN*, dopóki nie ustawisz ignore_default_excludes = false; Claude Code chroni tylko to, co wymienisz. Wyjście: usuń je albo zamaskuj, a produkcyjne poświadczenia trzymaj poza środowiskami agentów.
• Codex odrzuca flagi. codex -a untrusted i -a on-failure kończą się w 0.157.1 błędem „invalid value”, codex exec -a never błędem „unexpected argument”, a profil razem z --sandbox się nie składa. Wyjście: untrusted i granular ustaw w config.toml, -a podawaj przed exec, wybierz profile albo starsze flagi, nie oba naraz.
• Uruchomienie -p po cichu pomija zablokowaną pracę. W headless Claude Code z trybem auto trzy blokady klasyfikatora z rzędu albo 20 łącznie wstrzymują tryb auto; akcja się nie wykona, a Claude pracuje dalej. Wyjście: nie opieraj wyniku joba na kodzie wyjścia agenta; uruchom testy i lint w osobnym kroku CI i to one niech decydują o porażce.
• Sam agent ma błędy. Wśród advisory bezpieczeństwa Claude Code jest ucieczka z sandboksa przez pomylenie ścieżek git worktree (High, 2026-06-25) i obejście okna zaufania do workspace przez plik ustawień kontrolowany przez repozytorium (High, 2026-03-18). Wyjście: zostań na wspieranym kanale, dla klasy krytycznej zachowaj zewnętrzny kontener i powtarzaj test kanarkowy po każdej aktualizacji.

Dokąd dalej z harnessem agenta

• Przegląd harnessu pokazuje miejsce uprawnień obok kontekstu, narzędzi, hooków, skilli i środowisk.
• Model zagrożeń dla agentów pokazuje, które uruchomienia łączą prywatne dane, niezaufane wejście i drogę na zewnątrz.
• Hooki jako deterministyczne zabezpieczenia dodają kontrole, których warstwa zatwierdzania nie wyrazi.
• Środowiska efemeryczne dają każdemu uruchomieniu jednorazową granicę zewnętrzną.
• Porównanie agentów w tle i w chmurze omawia środowiska hostowane przez dostawców.
• Następny krok ścieżki developera: łańcuch artefaktów, który określa, jakie dowody musi zostawić po sobie każde uruchomienie bez nadzoru.