wskazówka, jeśli przechodzisz z cc do codex i brakuje ci flagi `--worktree`, oto obejście name=$(grep -E '^[a-z]{4,10}$' /usr/share/dict/words | shuf -n 3 | paste -sd- -) && git worktree add -b "worktree-$name" ".codex/worktrees/$name" && codex -C ".codex/worktrees/$name" zapisz to jako skrót w swoim `.zshrc`, a w zasadzie masz ekwiwalent, z wyjątkiem automatycznego czyszczenia

a oto fragment tej komendy, który pozwala ci zrobić coś w codex, czego NIE MOŻESZ zrobić z `--worktree` cc ogranicza codex do worktree, aby nie był zdezorientowany ani nie próbował uruchamiać testów czy pisać kodu poza nim name=$(grep -E '^[a-z]{4,10}$' /usr/share/dict/words | shuf -n 3 | paste -sd- -) && wt=".codex/worktrees/$name" && git worktree add -b "worktree-$name" "$wt" && codex -C "$wt" -s workspace-write -a never -c 'sandbox_workspace_write.network_access=true' czyni nowy worktree głównym katalogiem roboczym, utrzymuje codex w `workspace-write`, wyłącza monity o zatwierdzenie z `-a never` i włącza dostęp do sieci wewnątrz tej piaskownicy

jeszcze jedna wersja, która pozwala codex obsługiwać operacje git, takie jak commit/push/pr, ale utrzymuje ogrodzenie worktree codex pozostaje zakorzeniony w nowym worktree jako swoje miejsce pracy, może edytować i uruchamiać polecenia tam, a także może korzystać z sieci wewnątrz `workspace-write` dzięki nadpisaniu konfiguracji jeśli akcja git musi wyjść poza piaskownicę miejsca pracy, jak niektóre zapisy metadanych lub inne chronione operacje, codex może zatrzymać się i poprosić o zatwierdzenie zamiast po prostu niepowodzenia name=$(grep -E '^[a-z]{4,10}$' /usr/share/dict/words | shuf -n 3 | paste -sd- -) && wt=".codex/worktrees/$name" && git worktree add -b "worktree-$name" "$wt" && codex -C "$wt" -s workspace-write -a on-request -c 'sandbox_workspace_write.network_access=true'