Przepływy wieloagentowe w Codex: równoległe tory, subagenci i zadania w chmurze

Przepływ wieloagentowy w Codex dzieli zadanie na tory bez wspólnych plików, uruchamia po jednym agencie Codex na tor we własnym worktree Git lub kontenerze w chmurze i scala tory według zależności, gdy każdy przejdzie własną bramkę. Równoległe tory opłacają się tylko wtedy, gdy wspólne kontrakty trafiają do kodu jako pierwsze, a każdy tor jest weryfikowany osobno.

Twój epik ma pięć podzadań: migrację, API, zmianę w serwisie, stronę ustawień i testy end-to-end. Możesz uruchomić pięć sesji Codex naraz, ale przy ostatniej próbie dwie z nich przepisały ten sam plik barrel, trzecia wymyśliła własny kształt odpowiedzi, a ty spędziłeś popołudnie na rozplątywaniu merge’y. Ta strona jest dla programisty, który uruchamia agentów, i dla tech leada, który decyduje, ilu agentów działa naraz i co znaczy „gotowe” dla każdego z nich.

Co daje ci wieloagentowy układ pracy w Codex

• Regułę, co idzie równolegle, co pierwsze, a co musi zostać sekwencyjne.
• Cztery prompty do skopiowania: dekompozycja, fundament, wykonawca toru i rozwiązywanie konfliktu między torami.
• Skrypt, który uruchamia po jednym agencie codex exec na worktree Git, oraz bramkę toru, która odrzuca pracę spoza toru, zanim ją przeczytasz.
• Ustawienia config.toml, które ograniczają współbieżność i koszt subagentów.
• Kolejność scalania i test integracyjny, które dowodzą, że połączony wynik działa.

Polecenia i klucze konfiguracji na tej stronie sprawdzono 2026-09-26 w codex 0.157.1 (--help i kod źródłowy rust-v0.157.1).

Który tryb Codex obsługuje jaki rodzaj pracy równoległej?

Codex daje cztery sposoby uruchamiania agentów obok siebie. Różnią się tym, co izolują, a izolacja decyduje o tym, co może bezpiecznie działać równolegle.

Tryb	Jak uruchomić	Izolacja	Do czego
Subagenci w jednej sesji	Poproś o nich w prompcie; przełączaj przez /subagents	Jedna sesja; współbieżność ustawiasz w [agents] w config.toml	Praca głównie odczytowa: eksploracja kodu, przegląd jednego diffu z kilku stron
Zarządzane sesje w worktree	codex --worktree albo /worktree w trakcie sesji	Nowy zarządzany worktree Git na sesję	Tory interaktywne, które chcesz obserwować i korygować
Skryptowy codex exec	git worktree add, potem codex exec -C <katalog>	Worktree i gałąź, które nazywasz sam	Powtarzalne rozproszenie pracy ze skryptu, z zachowanymi logami
Zadania w chmurze	codex cloud exec --env ENV_ID	Kontener w chmurze na zadanie; do czterech prób każde	Długie tory, ciężkie buildy i best-of-N na trudnym torze

Aplikacja desktopowa Codex (codex app, macOS i Windows) realizuje ten sam wzorzec worktree, z jednym wątkiem na tor. Neowin podał (źródło wtórne, 2026-07-09), że działa ona teraz jako tryb Codex w aplikacji desktopowej ChatGPT. Konfigurację i sprzątanie worktree w każdym trybie opisuje strona izolowane zadania Codex w worktree Git.

Kiedy uruchamiać agentów Codex równolegle, a kiedy po kolei?

Zrównoleglaj fragment pracy tylko wtedy, gdy spełnia wszystkie trzy warunki:

• Ma własne pliki. Żaden inny tor nie tworzy ani nie edytuje tych samych ścieżek.
• Nie zależy od niczego, co inny tor wciąż pisze. Jego dane wejściowe są już na gałęzi bazowej.
• Da się go zweryfikować w izolacji. Ma własne testy, a type check i lint przechodzą na jego gałęzi bez pozostałych torów.

Wszystko inne wykonuj sekwencyjnie: migracje bazy danych, wspólne typy i interfejsy, rejestrację tras i schematów w plikach barrel oraz każdy krok, przed którym musisz podjąć decyzję, zanim ruszy następny.

Większość zestawów funkcji ma ten sam kształt. Cienki fundament (migracja, wspólne interfejsy, linie rejestracji) blokuje całą resztę, potem trzy do pięciu torów działa równolegle, a na końcu raz, po wszystkich scaleniach, odbywa się faza integracji. Konflikty prawie zawsze biorą się z pominięcia fundamentu: dwóch agentów dopisuje „jedną linijkę” do src/routes/index.ts albo każdy wymyśla własny EventPayload.

Zrealizuj zestaw funkcji jako równoległe tory Codex

Przykład to funkcja preferencji powiadomień: użytkownik wybiera e-mail, SMS lub push dla każdego typu powiadomienia. Te same kroki działają dla kwartalnej listy niezależnych funkcji; wydłuża się tylko lista torów.

1. Rozłóż pracę i zapisz plan do pliku. Uruchom poniższy prompt planistyczny w zwykłej sesji Codex na gałęzi bazowej. Przeglądaj plan, nie kod: tabela własności plików i kontrakty decydują o powodzeniu pracy równoległej. Zacommituj docs/plan/notification-prefs.md, bo każdy prompt toru się do niego odwołuje.

2. Najpierw zbuduj fundament, w jednej sesji. Uruchom prompt fundamentu w jednej sesji na gałęzi funkcji, na przykład feature/notification-prefs. Gdy testy przejdą, zacommituj wynik. Każdy tor startuje teraz z gałęzi, która ma już tabelę, wspólne typy i linie rejestracji, więc żaden tor nie musi dotykać wspólnego pliku.

3. Uruchom po jednym agencie na tor. Dla dwóch lub trzech torów, które chcesz obserwować, otwórz terminal na tor, uruchom codex --worktree z gałęzi funkcji i wklej prompt toru. Przy większej liczbie torów albo przebiegu, który chcesz powtarzać, użyj skryptu z następnej sekcji.

4. Obserwuj i koryguj, nie wchodząc w każdą rozmowę. codex agents (lub /agents w sesji) otwiera centrum dowodzenia agentami, w którym wyszukasz, otworzysz, przemianujesz i zatrzymasz sesje. Nazwij tam każdą sesję tak jak jej tor. Aby skorygować tor bez przełączania się do niego, dodaj wiadomość do kolejki po nazwie sesji: codex queue --thread prefs-api --message "Use the NotificationPreference type from src/types/notifications.ts; do not define a new one." Gdy jeden tor musi znać decyzję innego, oznacz to zadanie przez @ w prompcie zamiast wklejać jego wynik. Przed uruchomieniem kolejnej partii sprawdź /usage.

5. Sprawdzaj każdy tor osobno. Uruchom bramkę toru (poniżej) na każdej gałęzi, gdy tylko tor się skończy. Zarządzana sesja codex --worktree zostawia zmiany niezacommitowane w worktree nazwanym przez Codex, więc najpierw zacommituj tam pracę toru, a ścieżkę tego worktree (z git worktree list) podaj bramce jako czwarty argument. Tor, który nie przejdzie bramki, wraca do swojego agenta razem z jej wynikiem; jego diffu jeszcze nie czytasz.

6. Scalaj w kolejności zależności, potem uruchom integrację. Najpierw scal tor z najmniejszą liczbą punktów styku, a tor testów end-to-end na końcu. Po ostatnim scaleniu uruchom raz cały zestaw testów na gałęzi funkcji. Dopiero wtedy otwórz pull request i poproś w nim o @codex review, obok recenzentów z zespołu.

Prompt do skopiowania: rozłóż funkcję na równoległe tory

I want to build notification preferences with several parallel Codex agents:
- Users choose email, SMS or push for each notification type (order_update, marketing, security_alert, system).
- Preferences live in a new database table; defaults apply when a user has none.
- A CRUD API manages them; the notification service reads them before sending.
- A settings page at /settings/notifications edits them.

Read the codebase first. Then write docs/plan/notification-prefs.md with:
1. A FOUNDATION section: every change that more than one lane needs (migration, shared TypeScript types, route and schema registration lines). These run first, in one session.
2. A LANES table: one row per parallel lane with the lane name, the directories and files it may create or edit, the files it may read but never edit, and its definition of done (named test files and the commands that must pass).
3. A CONTRACTS section: the exact request and response shapes and the shared types each lane must import, with file paths.
4. An INTEGRATION section: what can only be tested after all lanes merge.
No two lanes may list the same file as editable. If that is impossible, move the file into FOUNDATION. Do not write any implementation code.

Prompt do skopiowania: fundament przed startem torów

Implement only the FOUNDATION section of docs/plan/notification-prefs.md on this branch:
- The notification_preferences migration and Drizzle schema, following the patterns in src/lib/db/schema/.
- The shared types and the API contract types listed under CONTRACTS, in src/types/notifications.ts.
- Every registration line the lanes would otherwise add: the route import in src/routes/index.ts and the schema export in src/lib/db/schema/index.ts, pointing at stub modules that return 501.
Do not implement any lane. Run the migration against the dev database, then run type check, lint and the full test suite, and paste each command with its result. Stop if any existing test fails.

Rozprosz tory ze skryptu przez codex exec

Skrypt tworzy po jednym worktree i gałęzi na tor z bieżącej gałęzi, instaluje zależności poza sandboksem, uruchamia równolegle po jednym nieinteraktywnym agencie na tor i commituje wynik każdego toru, żeby bramka miała czystą gałąź do sprawdzenia. Uruchom go z katalogu głównego repozytorium, na gałęzi z commitem fundamentu, z jednym plikiem promptu na tor w prompts/. Skrypt zatrzyma się, jeśli gałąź albo worktree toru już istnieje, więc przed ponownym uruchomieniem usuń poprzednie (wiersz „Stare worktree się mnożą” w sekcji Gdy równolegli agenci Codex zawodzą); to porzuca niescaloną pracę torów.

#!/usr/bin/env bash
# fan-out.sh: one codex exec agent per lane, each in its own worktree
set -euo pipefail
BASE=$(git rev-parse --abbrev-ref HEAD)
RUNS="$PWD/.codex-runs"
mkdir -p "$RUNS"
pids=(); lanes=()

for lane in api service ui; do
  wt="../wt-prefs-$lane"
  git worktree add -b "feat/prefs-$lane" "$wt" "$BASE"
  (cd "$wt" && npm ci --silent)   # installs need the network the sandbox withholds
  codex exec -C "$wt" \
    -c default_permissions=":workspace" \
    --json -o "$RUNS/$lane.md" \
    "$(cat "prompts/prefs-$lane.md")" < /dev/null > "$RUNS/$lane.jsonl" &
  pids+=("$!"); lanes+=("$lane")
done

failed=0
for i in "${!pids[@]}"; do
  wait "${pids[$i]}" || { echo "FAIL ${lanes[$i]}: codex exec exited non-zero"; failed=1; }
done
[ "$failed" -eq 0 ] || exit 1

for lane in api service ui; do
  git -C "../wt-prefs-$lane" add -A
  git -C "../wt-prefs-$lane" commit -m "prefs: $lane lane (codex exec)" || echo "$lane: nothing to commit"
done

Trzy decyzje w skrypcie są celowe. -c default_permissions=":workspace" wybiera wbudowany profil uprawnień workspace, który OpenAI przedkłada nad starszą flagę --sandbox; profile są w wersji beta (Codex CLI 0.138.0 i nowsze), więc w skryptach przypnij wersję CLI. npm ci instaluje z lockfile’a, więc pięć torów nie rozwiąże pięciu różnych drzew zależności. Commituje skrypt, a nie agent, więc wynik nie zależy od tego, czy sandbox agenta może pisać do wspólnego katalogu .git repozytorium. .codex-runs/ przechowuje końcową wiadomość i log zdarzeń JSONL każdego toru; dodaj go do .gitignore. Dwa zabezpieczenia nie dopuszczają nieudanego toru do commita: skrypt czeka na identyfikator procesu każdego toru i przerywa pracę, jeśli którykolwiek codex exec zakończył się błędem (gołe wait zwraca 0 niezależnie od wyniku), a < /dev/null jest potrzebne, bo codex exec dokleja do promptu dane z potoku stdin, więc skrypt uruchomiony w CI albo przez bash < plik przekazałby każdemu agentowi przypadkowe wejście.

Prompt do skopiowania: wykonawca toru (zapisz jako prompts/prefs-api.md)

You are the API lane of docs/plan/notification-prefs.md. Read that file and AGENTS.md first.

Build:
- GET /api/users/:userId/notification-preferences (create and return defaults on first read)
- PUT /api/users/:userId/notification-preferences/:type
- Zod validation on every input; a user may read and write only their own preferences.

Rules:
- Edit only the files the LANES table lists as editable for the API lane. If you need to change anything else, stop and report what and why instead of changing it.
- Import request and response types from src/types/notifications.ts. Do not define new shared types.
- Replace the 501 stub in src/routes/notifications/preferences.ts; do not touch src/routes/index.ts.

Done means: unit tests for validation and integration tests for both endpoints exist and pass, and type check, lint and the full test suite pass. End with the commands you ran, their results, and the list of files you changed.

Prompty torów serwisu i UI pisz tak samo: nazwa toru, jego pliki do edycji, kontrakt, który importuje, i definicja ukończenia z poleceniami. Prompt toru bez „edytuj tylko” zaprasza agenta do poprawiania wszystkiego, co zauważy po drodze, a stąd biorą się konflikty między torami.

Jak udowodnić poprawność toru bez czytania każdego diffu?

Zanim cokolwiek przeczytasz, niech tor przejdzie automatyczne kontrole, w tej kolejności. Każda warstwa jest tańsza od następnej, więc tor trafia do człowieka dopiero po przejściu tanich kontroli.

Warstwa	Co wyłapuje	Jak
Granica toru	Agent edytował pliki spoza toru	git diff --name-only względem dozwolonych ścieżek toru
Testy toru i kontrole statyczne	Zepsute zachowanie wewnątrz toru	Własne testy toru, type check i lint na jego gałęzi
Agent recenzent	Dryf kontraktu, brakujące testy, błędy logiki	Przebieg codex exec z profilem uprawnień :read-only, z planem jako kryterium
Testy kontraktowe na styku	Tory, które przechodzą osobno, ale się nie zgadzają	Testy importujące wspólne typy z obu stron, napisane w fundamencie
Przebieg integracyjny	Interakcje: wspólny stan testów, porty, kolejność	Cały zestaw testów raz, po ostatnim scaleniu
Akceptacja człowieka	Zły plan, zły kontrakt, ryzykowne pliki	Zatwierdzasz plan i kontrakty przed startem, a diffy czytasz tylko w plikach, które plan oznacza jako ryzykowne (autoryzacja, płatności, migracje)

Bramka toru automatyzuje pierwsze trzy warstwy. Uruchom ją z katalogu głównego repozytorium raz dla każdego ukończonego toru:

#!/usr/bin/env bash
# lane-gate.sh LANE ALLOWED_PATHS_REGEX [BASE] [WORKTREE]
# example: ./lane-gate.sh api '^(src/routes/notifications/|src/services/notifications/api|tests/.*notification)'
set -euo pipefail
lane="$1"; allowed="$2"; base="${3:-feature/notification-prefs}"; wt="${4:-../wt-prefs-$lane}"
runs="$PWD/.codex-runs"
cd "$wt"

test -z "$(git status --porcelain)" || { echo "FAIL $lane: uncommitted changes"; exit 1; }

stray=$(git diff --name-only "$base"...HEAD | grep -v -E "$allowed" || true)
if [ -n "$stray" ]; then echo "FAIL $lane: files outside the lane:"; echo "$stray"; exit 1; fi

npm run typecheck
npm run lint
npm test

codex exec -c default_permissions=":read-only" -o "$runs/$lane-review.md" \
  "Review git diff $base...HEAD against docs/plan/notification-prefs.md. Report only correctness bugs, contract drift from src/types/notifications.ts, and behaviour without a test. Give file and line for each finding. If there are none, reply with exactly NO FINDINGS on its own line." < /dev/null
[ "$(tr -d '[:space:]' < "$runs/$lane-review.md")" = 'NOFINDINGS' ] || { echo "FAIL $lane: review findings in $runs/$lane-review.md"; exit 1; }
echo "PASS $lane"

Krok recenzji to zwykły przebieg codex exec, a nie codex exec review, bo codex exec review --base odrzuca własny prompt: --base i własny prompt wzajemnie się wykluczają (sprawdzone w codex 0.157.1), więc nie da się podać planu jako kryterium. Jeśli wolisz codex exec review --base "$base", uruchom je bez promptu, a kryteria wpisz do wytycznych przeglądu w AGENTS.md. Bramka nie przechodzi, jeśli plik recenzji zawiera cokolwiek poza NO FINDINGS (nie licząc białych znaków), więc recenzja, która wymienia uwagi i dopisuje też tę linię, i tak zostaje odrzucona; wtedy przeczytaj uwagi i odeślij je agentowi toru albo sam odrzuć fałszywy alarm. Każda kontrola stoi w osobnej linii, bo przy set -e błąd polecenia przed ostatnim && w łańcuchu nie zatrzymuje skryptu, więc nieudany type check i tak wypisałby PASS.

Tor, który nie przejdzie kontroli granicy, odeślij do jego agenta albo przenieś zabłąkany plik do fundamentu i zaplanuj od nowa. Nie scalaj toru, żeby potem ręcznie naprawić nakładanie się: tak zaczyna się konflikt następnego toru. Przegląd kodu w skali zespołu opisują strategie przeglądu kodu w Codex i kolejka code review, gdy pull requesty otwierają agenci.

Rozprosz pracę w jednej sesji przez subagentów Codex

Subagenci są domyślnie włączeni (multi_agent ma status stable w 0.157.1). Agent sesji tworzy ich, gdy prompt prosi o pracę równoległą, a /subagents przełącza między nimi. Lepiej nadają się do pytań niż do edycji: kilku czytelników przegląda jedną bazę kodu albo kilku recenzentów jeden diff. Tory, które zapisują pliki, trzymaj w osobnych worktree, gdzie izoluje je Git.

Ogranicz ich w ~/.codex/config.toml. Każdy klucz poniżej występuje w schemacie konfiguracji 0.157.1:

[agents]
max_threads = 4                                # alias of max_concurrent_threads_per_session
default_subagent_reasoning_effort = "medium"   # used when the spawn call sets none
# default_subagent_model = "gpt-6-sol"         # only after your own evals favour it

[agents.reviewer]
description = "Read-only reviewer. Reports findings with file and line; never edits files."
config_file = "./agents/reviewer.toml"          # a config layer, relative to this file

[goals]
max_goal_token_budget = 2000000                 # nested subagent tokens count toward it

Zostaw default_subagent_model nieustawione, dopóki nie masz powodu. Codex domyślnie korzysta z GPT-6 Astra, a zasada tej dokumentacji brzmi: najpierw dostrój effort, dopiero potem zmieniaj model; aktualne modele Codex i ich ceny znajdziesz w przeglądzie modeli. Od wersji 0.151.0 tokeny zużyte przez zagnieżdżonych subagentów wliczają się do budżetu /goal, więc budżet celu ogranicza też rozproszenie pracy.

Prompt do skopiowania: równoległy przegląd przez subagentów

Spawn three reviewer subagents over the diff between feature/notification-prefs and main. None of them may edit files.
1. Security: authorization on every preferences endpoint (a user must never read or write another user's preferences), input validation, and anything logged.
2. Contracts: every consumer of src/types/notifications.ts uses the types unchanged; no lane redefined a shape.
3. Tests: behaviour in the diff that no test covers, and any test that was weakened, skipped or had its assertions changed.
Wait for all three, deduplicate their findings, and give me one list ordered by severity, each with file, line and a one-sentence fix.

Wyślij długie lub ryzykowne tory do chmury Codex

Tor, który wymaga ciężkiego buildu, działa długo albo ma kilka sensownych projektów rozwiązania, lepiej pasuje do zadania w chmurze niż do worktree na laptopie. Najpierw wypchnij gałąź fundamentu: codex cloud exec działa na bieżącej gałęzi, chyba że podasz --branch (sprawdzone w codex cloud exec --help, 0.157.1), a kontener klonuje repozytorium z remote’a.

# run in your terminal, inside the repository
git push -u origin feature/notification-prefs
codex cloud exec --env ENV_ID --branch feature/notification-prefs --attempts 2 - < prompts/prefs-service.md
codex cloud list --env ENV_ID          # watch progress
codex cloud diff TASK_ID --attempt 2   # compare attempts
# apply the chosen attempt inside the lane's own worktree, commit it, then gate it
git worktree add -b feat/prefs-service ../wt-prefs-service feature/notification-prefs
(cd ../wt-prefs-service && codex cloud apply TASK_ID --attempt 2 \
  && git add -A && git commit -m "prefs: service lane (cloud)")
./lane-gate.sh service "$SERVICE_PATHS"   # the service lane's allowed-paths regex

ENV_ID to identyfikator lub etykieta środowiska w chmurze, a TASK_ID to identyfikator lub URL, który wypisuje codex cloud exec. codex cloud apply zapisuje diff w katalogu roboczym, w którym je uruchamiasz, więc uruchom je w worktree toru i zacommituj wynik przed bramką, która odrzuca niezacommitowane zmiany. Dzięki temu tor z chmury przechodzi tę samą bramkę co tor lokalny. Tor wysłany do chmury usuń z listy for lane in w fan-out.sh, inaczej oba sięgną po ten sam worktree. Konfigurację środowiska, dostęp do internetu i to, kiedy best-of-N jest wart swojej ceny, opisuje strona środowiska chmurowe Codex.

Ilu agentów Codex uruchamiać naraz?

Liczbę agentów ustalaj według przepustowości code review, nie według tego, na co pozwala komputer albo plan. Raport Faros AI „AI Engineering Report 2026” (kwiecień 2026, telemetria od 22 000 programistów) pokazał wzrost przepustowości zadań na programistę o 33,7%, przy jednoczesnym wzroście mediany czasu w code review o 441,5% i liczby incydentów na pull request o 242,7%. Więcej generowania bez większej weryfikacji przesuwa kolejkę do code review, a koszt na produkcję.

Praktyczne limity, które z tego wynikają:

• Zacznij od trzech torów. Czwarty dodaj dopiero wtedy, gdy bramki pierwszych trzech przechodzą bez poprawek. Pięć torów na programistę traktuj jako sufit, który trzeba uzasadnić, a nie cel.
• Jeden właściciel scalania. Tory scala autor planu, bo kolejność scalania wynika z planu.
• Budżet przed startem. Przed uruchomieniem partii sprawdź /usage w sesji, ustaw max_threads dla subagentów i budżet /goal na długich torach. Limity planów i ich okna pięciogodzinne i tygodniowe opisuje strona zarządzanie kosztami Codex.

Gdy równolegli agenci Codex zawodzą

Objaw	Przyczyna	Naprawa
Konflikty w src/routes/index.ts lub innym pliku barrel	Kilka torów zarejestrowało się samodzielnie	Przenieś rejestrację do fundamentu ze stubami, jak w prompcie fundamentu. Przy merge’u, który już ma konflikt, użyj promptu poniżej
Tory przechodzą osobno, a razem nie	Wspólny stan testów, stałe porty albo dwa tory zasilające tę samą tabelę	Dodaj brakujący test kontraktowy do fundamentu, odizoluj dane testowe per zestaw, uruchom integrację ponownie
Dwa tory nie zgadzają się co do kształtu odpowiedzi	Kontrakt zostawiono agentom	Umieść kształt w src/types/notifications.ts w fundamencie; dodaj do kolejki obu torów wiadomość, która na niego wskazuje
Bramka zgłasza pliki spoza toru	W prompcie zabrakło „edytuj tylko” albo plan przeoczył wspólny plik	Odeślij wynik bramki agentowi albo przenieś plik do fundamentu i zaplanuj od nowa
Torowi w chmurze brakuje fundamentu	Gałąź nie została wypchnięta albo --branch wskazywał inną	Wypchnij gałąź fundamentu i wyślij zadanie ponownie z --branch
npm ci lub buildy wyczerpują laptopa	Pięć worktree naraz instaluje i testuje	Rozłóż starty w czasie albo przenieś najcięższe tory do chmury
Tor utknął lub się zapętlił	Niejasna definicja ukończenia albo pełne okno kontekstu	Zatrzymaj go w codex agents, doprecyzuj definicję ukończenia w prompcie toru i uruchom nową sesję w tym samym worktree
Stare worktree się mnożą	Każdy tor zostawia worktree i gałąź	Po scaleniu: git worktree remove ../wt-prefs-api, git branch -d feat/prefs-api, a potem git worktree prune

Prompt do skopiowania: rozwiąż konflikt między dwoma torami

Merging feat/prefs-service into feature/notification-prefs left conflict markers in src/services/notifications/preferences.ts. The plan in docs/plan/notification-prefs.md gave that file to both the API lane and the service lane by mistake: the API lane added preference reads with defaults, and the service lane added channel filtering. Resolve every conflict so both behaviours survive; do not drop either side. Keep the shared types from src/types/notifications.ts unchanged, deduplicate imports, and keep the existing error handling. Then run type check, lint and the notification test suites, and report each command with its result.

Nie usuwaj worktree, zanim jego gałąź zostanie scalona

git worktree remove usuwa katalog roboczy, a git branch -D porzuca commity, których nie ma żadna inna gałąź. Najpierw scal lub wypchnij gałąź każdego toru, dopiero potem sprzątaj.

Co dalej z pracą wieloagentową w Codex

• Przed tą stroną: izolowane zadania Codex w worktree Git i pisanie AGENTS.md dla Codex. Każdy tor czyta z AGENTS.md polecenia budowania i testów.
• Przebiegi skryptowe w szczegółach: nieinteraktywny Codex z codex exec.
• To samo rozproszenie na dziesiątki plików lub repozytoriów: operacje wsadowe w Codex.
• Jak utrzymać mały kontekst każdego toru: wzorce kontekstu w Codex.
• Wzorce niezależne od narzędzia (planista, wykonawcy, sędzia): wzorce orkiestracji wielu agentów.
• Odpowiednik w Claude Code: własni subagenci w Claude Code.