Współpraca zespołowa i wspólna konfiguracja

Przepływy zespołowe w Codeksie ujednolicają sesję każdego dewelopera trzema zacommitowanymi plikami: .codex/config.toml z modelem, piaskownicą i serwerami MCP, .codex/rules/ z tym, co wolno uruchomić poza piaskownicą, i .agents/skills/ ze wspólnymi skillami. Konwencje niesie AGENTS.md, requirements.toml wymusza to, czego nikt nie nadpisze, a routing profili trzyma zużycie kredytów w ryzach.

Dwunastu deweloperów, dwanaście konfiguracji Codeksa. Jeden puszcza wszystko przez --yolo. Drugi trzyma restrykcyjną politykę zatwierdzania i ręcznie ogląda każdą nieznaną komendę. Trzeci ma pięć serwerów MCP, z których nikt inny nie korzysta, a które zjadają tokeny kontekstu w każdej sesji. Gdy wymieniają się promptem, wyniki rozjeżdżają się na wszystkie strony i nikt nie wie, czy zawinił prompt, czy konfiguracja.

Ujednolicenie konfiguracji w zespole to największa dostępna tu dźwignia, a kosztuje jedno popołudnie. Baza jest wspólna, a indywidualna swoboda zostaje tam, gdzie powinna.

Co daje wspólna konfiguracja zespołowa

Strategię wdrożenia wspólnego config.toml, reguł i skilli oraz kolejność pierwszeństwa rozstrzygającą, która warstwa wygrywa
Konwencje AGENTS.md działające w zespołach od 5 do 50 osób
Szablony onboardingu i skill, po których nowa osoba pracuje produktywnie po jednym dniu
Wzorce biblioteki promptów do dzielenia się sprawdzonymi przepływami
Mechanizmy nadzoru: RBAC, requirements.toml i raportowanie zgodności
Strategie kosztowe, dzięki którym zużycie kredytów w zespole jest przewidywalne

Trzy pliki, które zespół commituje

Codex czyta konfigurację z wielu warstw. Najprostszy sposób na ujednolicenie jednego repozytorium to zacommitowanie warstwy projektowej obok kodu:

Typ	Ścieżka	Do czego służy
Konfiguracja	`.codex/config.toml`	Model, tryb piaskownicy, polityka zatwierdzania, serwery MCP
Reguły	`.codex/rules/`	Które komendy Codex może uruchomić poza piaskownicą
Skille	`.agents/skills/`	Wspólne skille dostępne dla całego zespołu

Konfiguracja na poziomie projektu

# .codex/config.toml -- Shared team defaults
# Portable baseline; eligible users can add a separate Sol profile file.
model = "gpt-5.6-terra"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

# Shared MCP servers
[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"

# Disable web search for security-sensitive projects
web_search = "disabled"

Model bazowy dobierz tak, by pasował do wszystkich, którzy będą go używać. Plany Free i Go dają Terrę; uprawnieni użytkownicy Plus, Pro, Business i Enterprise mogą wybierać między Sol, Terrą i Luną, a administrator zarządzanego workspace’u może to jeszcze zawęzić rolami. Sol traktuj jako profil opcjonalny, nigdy jako domyślny w pliku, który dziedziczą wszyscy.

Ta wersja trzyma wspólny plik przenośnym i wsadza Sol do osobnej konfiguracji, po którą deweloper sięga świadomie. W zespole, w którym wszyscy mają uprawnienia do Sol, model do review możesz wpisać do tego samego pliku:

Po wklejeniu któregokolwiek z wygenerowanych plików sprawdź dwa klucze: shell_snapshot mieszka w tabeli [features] ([features], a pod spodem shell_snapshot = true), a nie na najwyższym poziomie, natomiast nadpisanie dla /review to klucz review_model na najwyższym poziomie.

Która warstwa wygrywa

Zacommitowany .codex/config.toml projektu bije konfigurację profilową i osobistą i właśnie dlatego jest bazą zespołu. Na pojedynczy przebieg nadpiszą go tylko flagi CLI i -c key=value; warstwa --profile siedzi poniżej konfiguracji projektu. Jeśli deweloper oznaczy projekt jako niezaufany, Codex pomija warstwy .codex/ w całości i schodzi do profilu, konfiguracji osobistej, systemowej i wbudowanych domyślnych — to pierwsza rzecz do sprawdzenia, gdy wyniki jednej osoby nie zgadzają się z resztą. Ograniczenia, których nikt nie ma prawa obejść, wpisuj do requirements.toml, a nie do konfiguracji projektu.

Pliki reguł i dlaczego to nie TOML

Reguły to pliki .rules pisane w Starlarku, języku konfiguracyjnym przypominającym Pythona, umieszczane w .codex/rules/. Sterują tym, które komendy agent może uruchomić poza piaskownicą:

# Allow common package managers (a union of literals at the first position)
prefix_rule(
    pattern = [["npm", "pnpm", "yarn"]],
    decision = "allow",
)

# Allow git and make
prefix_rule(pattern = ["git"], decision = "allow")
prefix_rule(pattern = ["make"], decision = "allow")

# Prompt before potentially destructive commands
prefix_rule(
    pattern = ["rm"],
    decision = "prompt",
    justification = "Deletion requires review",
)

Każda reguła to wywołanie prefix_rule(). pattern jest listą dopasowywaną do listy argumentów komendy, a zagnieżdżona lista w rodzaju ["npm", "pnpm", "yarn"] pasuje do dowolnej z tych alternatyw na danej pozycji. Decyzje to allow, prompt albo forbidden, a gdy pasuje kilka reguł, Codex stosuje najbardziej restrykcyjną. Po edycji reguł zrestartuj Codeksa.

Wspólne konwencje AGENTS.md

Ułóż hierarchię tak, by każdy plik niósł wyłącznie to, co prawdziwe na jego poziomie:

AGENTS.md                           # Repository-wide conventions
  |-- packages/api/AGENTS.md        # API team conventions
  |-- packages/web/AGENTS.md        # Frontend team conventions
  |-- services/payments/AGENTS.md   # Payments team conventions

Co trafia do korzenia

Konwencje obowiązujące w całej bazie kodu:

# Team Conventions

## Code Style
- Use TypeScript strict mode for all new files
- Follow the error handling patterns in src/lib/errors.ts
- All API routes must have OpenAPI annotations

## Workflow
- Run pnpm lint && pnpm test before committing
- New endpoints need integration tests in tests/integration/
- Database changes need a migration file in migrations/

## Review
- Security-sensitive changes require two human reviewers
- Performance changes need benchmark results in the PR description

Co trafia do plików na poziomie pakietu

Wyłącznie reguły właściwe dla tego pakietu — wszystko powtórzone z korzenia to zmarnowany budżet wobec limitu 32 KB:

## API-Specific Rules
- Use the centralized error handler, never throw raw errors
- Rate limiting must be added to all public endpoints
- Authentication middleware is in src/middleware/auth.ts
- Test utilities are in tests/utils/api-helpers.ts

Wspólne skille

Skill zespołowy, który wywoła każdy

Skill to katalog zawierający SKILL.md. Commituj je do .agents/skills/ w korzeniu repozytorium — przykład poniżej to zawartość .agents/skills/pr-ready/SKILL.md, a nie luźny plik markdown wrzucony wprost do .agents/skills/:

---
name: pr-ready
description: Prepare the current changes for a pull request by running
  all checks, fixing issues, and generating a PR description.
---

# PR Readiness Check

1. Run pnpm lint and fix any issues
2. Run pnpm test and fix any failures
3. Run pnpm type-check and fix any errors
4. Generate a PR description with:
   - Summary of changes
   - Testing approach
   - Breaking changes (if any)
5. Report the results

Członkowie zespołu wywołują go przez $pr-ready na dowolnej powierzchni Codeksa. Sensowny zestaw startowy wygląda tak:

.agents/skills/
  pr-ready/SKILL.md          # PR preparation
  review-security/SKILL.md   # Security-focused review
  migrate-db/SKILL.md        # Database migration helper
  onboard/SKILL.md           # New developer orientation

Gdzie mieszkają skille: osobiste, zespołowe, firmowe

Osobiste: ~/.agents/skills/ — prywatne skróty do własnej produktywności
Zespołowe: .agents/skills/ w repozytorium — wspólne dla każdego, kto je sklonuje
Firmowe: /etc/codex/skills/ — rozdawane przez zarządzanie konfiguracją na wszystkie maszyny

Wdrożenie nowej osoby w zespole

Lista kontrolna

Zainstaluj ChatGPT na desktop i CLI (curl -fsSL https://chatgpt.com/codex/install.sh | sh; na Windowsie użyj oficjalnego instalatora PowerShell)
Uruchom codex login, żeby uwierzytelnić się w zespołowym workspace ChatGPT
Sklonuj repozytorium (jest w nim .codex/config.toml i AGENTS.md)
Zainstaluj zalecane serwery MCP: codex mcp add linear --url https://mcp.linear.app/mcp
Odpal zadanie testowe: codex "Summarize the current instructions and list available skills"
Przejrzyj wspólne skille zespołu przez /skills i bibliotekę promptów w .github/codex/prompts/

Skill onboardingowy

Lepsze niż dokument, którego nikt nie czyta: skill, który przeprowadza nową osobę po projekcie przy jej pierwszej interakcji z Codeksem.

---
name: onboard
description: Guide a new team member through the project setup and conventions.
---

# Onboarding Guide

1. Summarize the repository structure and key directories
2. List all AGENTS.md files and summarize the team conventions
3. List all available skills and explain what each one does
4. Run the test suite and report the results
5. Identify the most recently changed files to show current work areas
6. Suggest the first 3 tasks a new team member should tackle

Nowi deweloperzy uruchamiają $onboard przed czymkolwiek innym.

Biblioteki promptów

Prompty, które się sprawdziły, wrzuć do repozytorium, gdzie przechodzą review i poprawki jak kod:

.github/codex/prompts/
  review.md          # PR review prompt
  fix-ci.md          # CI failure auto-fix
  migration.md       # Database migration template
  security-scan.md   # Security audit prompt
  perf-check.md      # Performance regression check

Deweloperzy powołują się na nie w rozmowach, używają jako instrukcji skilli albo wpinają w GitHub Actions. Po ten do naprawy CI zespoły sięgają zwykle jako pierwszy:

The CI pipeline failed on this branch. Here is the error output:
[paste CI output]

Diagnose the failure. If it is a test failure, find the root cause in the
source code and fix it. If it is a linting or type error, fix it. Run the
full test suite after the fix to verify no regressions. Report what you
changed and why.

Nadzór, którego nikt nie obejdzie

Konfiguracja projektu ustawia domyślne, requirements.toml ustawia granicę. Administratorzy wdrażają go do /etc/codex/requirements.toml (albo przez MDM), żeby wymusić ograniczenia, których żaden deweloper nie nadpisze:

# /etc/codex/requirements.toml (or deployed via MDM)
allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

# Only allow specific MCP servers
[mcp_servers.linear]
identity = { url = "https://mcp.linear.app/mcp" }

To właśnie blokuje uruchomienie --yolo czy włączenie danger-full-access. Workspace’y ChatGPT Business i Enterprise dokładają do tego kontrolę dostępu opartą na rolach — Admin z pełną konfiguracją, zarządzaniem środowiskami i analityką, Member ze standardowym użyciem w granicach wyznaczonych przez administratora, Restricted z dostępem tylko do odczytu i ograniczonym wyborem modeli — a samo logowanie da się przypiąć do jednego workspace’u:

forced_chatgpt_workspace_id = "your-workspace-uuid"
forced_login_method = "chatgpt"

Plany Enterprise wystawiają też dwa API warte wpięcia w dashboard: Analytics API ze zużyciem tokenów, wskaźnikami ukończenia zadań i aktywnością per użytkownik oraz Compliance API do audytu tego, jakie komendy agent uruchomił, które pliki zmodyfikował i jakie zgody zostały udzielone.

Panowanie nad kosztami

Strategia	Na czym polega
Warstwowanie modeli	GPT-5.6 Terra do prostych zadań, GPT-5.6 Sol do złożonych
Routing przez profile	Utwórz profile `quick` i `deep` z różnymi modelami
Limity zadań w chmurze	Planuj budżet z aktualnego cennika tokenowego i panelu workspace’u
Dyscyplina kontekstu	Trzymaj AGENTS.md zwięzłym, wyłączaj nieużywane serwery MCP

Po konkretne liczby idź do panelu zużycia ChatGPT/Codex — to tam siedzi przydział przypisany do konta i saldo kredytów. codex login status sprawdza uwierzytelnienie i nie jest licznikiem kredytów, a codex cloud list --json inwentaryzuje zadania, ale nie zastępuje danych rozliczeniowych.

Cztery nawyki odpowiadają za większość oszczędności:

Zaczynaj małym, eskaluj świadomie. Do wstępnego rozpoznania używaj --profile quick, a do ostatniego przejścia --profile review.
Grupuj podobne zmiany. Powiązane pliki w jednej sesji biją jedną sesję na plik.
Wznawiaj zamiast zaczynać od nowa. Wznowiona sesja nie czyta bazy kodu drugi raz.
Wyłączaj wyszukiwanie w sieci, gdy nie jest potrzebne. Dokłada wywołań narzędzi, kontekstu, opóźnień i kontaktu z niezaufaną treścią.

Gdzie zespołowe konfiguracje Codeksa się sypią

Konfiguracja zespołowa kłóci się z osobistą. Zacommitowany .codex/config.toml projektu ma pierwszeństwo przed profilową i osobistą, a przebijają go tylko flagi CLI albo -c. Gdy projekt jest oznaczony jako niezaufany, warstwy projektowe są pomijane w całości. Najpierw sprawdź stan zaufania i jednorazowe nadpisania z CLI, a wszystko, co musi obowiązywać, przenieś do requirements.toml.
AGENTS.md jest za duży. Łączny rozmiar wszystkich plików AGENTS.md domyślnie nie przekracza 32 KB. Rozbij wskazówki na pliki zagnieżdżone, wytnij to, co korzeń już mówi, a project_doc_max_bytes podnoś tylko wtedy, gdy naprawdę trzeba.
Nowa osoba dostaje inne wyniki. Sprawdź zaufanie do projektu, uprawnienia do modelu, wybrany profil zewnętrzny, dostępność MCP i zabłąkane nadpisania z CLI — w tej kolejności.
requirements.toml wygląda na ignorowany. Upewnij się, że leży we właściwym miejscu (/etc/codex/requirements.toml albo wdrożony przez administratora workspace’u) i sprawdź uprawnienia pliku.
Zespół nie widzi skilli. Skille muszą leżeć w katalogach .agents/skills/ w repozytorium, a Codex skanuje od bieżącego katalogu w górę do korzenia. Sprawdź, czy są zacommitowane i wypchnięte, a jeśli świeżo dodany skill się nie pojawia, zrestartuj Codeksa.

Dokąd dalej z zespołową konfiguracją Codeksa

Instalacja i konfiguracja — konfiguracja indywidualna uzupełniająca ustawienia zespołowe
Optymalizacja AGENTS.md — skaluj AGENTS.md na potrzeby zespołu
Nadzór korporacyjny — przenieś te mechanizmy na poziom organizacji
Strategie review — ujednolić praktyki review na bazie wspólnej konfiguracji