Blogg

Codex worktree: en separat arbeidskopi for en annen oppgave

Markdown

Arbeidskopi av Codex CLI 0.155.1: eksperimentelt worktree-flagg, kilde-HEAD, kontroll av den nye mappen, bevaring av resultatet og trygg fjerning.

Les hele artikkelen

Viktigste poeng

I Codex CLI versjon 0.155.1 oppretter du en separat arbeidskopi for en annen oppgave med codex --enable worktrees --worktree. Funksjonen er eksperimentell og deaktivert som standard: Hvis du ikke allerede har aktivert den, vil Codex nekte å starte med --worktree uten --enable worktrees. Kopien opprettes fra den siste committen i det opprinnelige prosjektet (HEAD), uten ucommittede endringer, i tilstanden detached HEAD — uten en tilknyttet navngitt branch.

Tenk deg at du bruker Codex CLI til å refaktorere én modul når det dukker opp en ny oppgave: å skrive tester for en annen modul. Det er risikabelt å åpne en ny økt i samme mappe: Det er lett å blande sammen endringer fra den første og den andre oppgaven. Flagget --worktree oppretter en separat mappe med en kopi av det samme prosjektet for den andre oppgaven, mens den første mappen forblir urørt.

Praktiske ressurser om å jobbe parallelt med agenter: Ailoot-dokumentasjonen.

Hva --worktree oppretter, og hvilke filer som blir med i kopien

I Git-terminologi er en worktree en ekstra arbeidsmappe som er knyttet til det samme repositoriet: Den deler commit-historikken, men har sitt eget sett med filer på disken. I Codex CLI 0.155.1 bruker flagget --worktree denne Git-mekanismen til å starte en ny agentsesjon i en separat mappe, slik at mappen der den første oppgaven allerede pågår, forblir urørt.

Den nye arbeidskopien inneholder filene fra committen som HEAD i det opprinnelige prosjektet peker på når den startes — den siste committen, ikke siste gang du lagret en fil i redigeringsprogrammet. Kommandoen overfører ikke ucommittede endringer eller nye filer. Å lagre i redigeringsprogrammet er ikke det samme som å committe i Git. Hvis den første mappen fortsatt inneholder ucommittede endringer når du starter den andre oppgaven, blir endringene bare værende i den mappen.

Dette er verken en sikkerhetskopi av hele repositoriet eller en isolering av hele datamaskinen. Det er en ekstra arbeidsmappe for det samme prosjektet, med tilgang til den samme branchen og commit-historikken. Hvis du vil se en lignende mekanisme i et annet verktøy, kan du lese Claude Code og git worktree: parallelle oppgaver.

Forberedelser: versjon, prosjekttillit og en commit

Kontroller tre ting før du begynner. Kjør kommandoene fra mappen til det opprinnelige prosjektet.

Først må du kontrollere versjonen av Codex CLI. Disse instruksjonene gjelder for versjon 0.155.1. For andre versjoner bør du kontrollere flaggenes virkemåte separat:

codex --version

For det andre trenger du et lokalt Git-prosjekt der HEAD peker på en eksisterende commit — med andre ord må repositoriet inneholde minst én commit. Ellers finnes det ingenting å opprette kopien fra.

For det tredje må kilden være klarert: Hvis prosjektet uttrykkelig er merket som en ikke-klarert kilde, mislykkes oppstart med --worktree før kopien blir opprettet. Hvis du nettopp setter opp Codex CLI, finner du grunnleggende forberedelser i Codex (OpenAI): hva det er, og hvordan du kommer i gang.

Kontroller listen over eksisterende worktrees i repositoriet på forhånd. Du kan sammenligne med den etter oppstart:

git worktree list

Separate mapper bidrar til å holde oppgavene fra hverandre. For en overordnet tilnærming til arbeid med en agent er de praktiske ressursene i Ailoot-dokumentasjonen nyttige.

Trinn: start en separat kopi for en annen oppgave

  1. Aktiver den eksperimentelle funksjonen, og start en økt med en separat kopi

    Kjør kommandoen fra mappen til det opprinnelige prosjektet, der du allerede arbeider med den første oppgaven.

    codex --enable worktrees --worktree
    

    Forventet resultat: Codex oppretter en ny arbeidskopi av prosjektet fra gjeldende HEAD og åpner en agentsesjon der. Kopien er i tilstanden detached HEAD, uten en tilknyttet navngitt branch. Slik fungerer flagget i versjon 0.155.1.

  2. Vis listen over worktrees på nytt i en annen terminal i det opprinnelige prosjektet

    git worktree list
    

    Forventet resultat: Utdataene inneholder en ekstra linje med banen til den nye kopien og en markør for detached HEAD (eller en branch, hvis det finnes en). Listen viser at Git har registrert kopien, men bekrefter ikke at agenten har fullført oppgaven. Åpne mappen på den oppførte banen og kontroller innholdet for å forsikre deg om at filene er der.

Slik kontrollerer du resultatet og tar vare på arbeidet ditt

Når den andre oppgaven i den nye kopien er fullført, må du lagre og overføre resultatet separat. Kommandoen --worktree fletter ikke endringene inn i hovedbranchen og overfører heller ikke resultatet automatisk. Kopien forblir i tilstanden detached HEAD, så det å opprette en commit i den oppretter ikke i seg selv en ny branch. Hvis du trenger å ta vare på disse committene, må du knytte dem til en branch eller overføre dem til hovedprosjektet før du sletter mappen til kopien.

Ikke slett mappen til kopien før resultatet er tatt vare på. Å kontrollere at arbeidsmappen er ren, erstatter ikke bevaring av committene du trenger: De kan fortsatt være uten en tilknyttet branch.

Hvis du arbeider med oppgaver i ulike verktøy samtidig, bør du planlegge på forhånd hvordan du skal unngå at de kommer i konflikt. Claude Code og Codex sammen handler om å jobbe med to agenter samtidig.

Hvis oppstarten ble avbrutt: hvor du finner kopien

Oppstart med --worktree kan mislykkes av flere grunner:

  • funksjonen var ikke aktivert på forhånd, og oppstartskommandoen inneholder ikke --enable worktrees: Codex vil nekte å starte med flagget --worktree;
  • du befinner deg i feil mappe, eller det finnes ingen commit: Hvis gjeldende mappe ikke er et Git-repositorium eller ikke inneholder noen commit ennå, finnes det ingenting å opprette kopien fra;
  • prosjektet er uttrykkelig merket som en ikke-klarert kilde: Codex vil nekte å starte en økt med --worktree. Kontroller først at du har åpnet riktig prosjekt. Ikke endre tillitsstatusen automatisk.

Hvis økten ikke klarte å koble seg til den nyopprettede kopien — for eksempel fordi prosessen ble avbrutt — slettes ikke arbeidsmappen automatisk. Kontroller først listen over worktrees. Før du sletter noe, må du forsikre deg om at ingen Codex CLI-økt fortsatt bruker denne kopien:

git worktree list

Åpne mappen og lagre eventuelle endringer du trenger før du sletter den. Kopien kan bli liggende selv om agentsesjonen ikke ble ferdig med å starte. Hvis kopien finnes, ikke lenger er nødvendig, og du er helt sikker på at ingen økt bruker den, kan du fjerne den manuelt fra det opprinnelige repositoriet med git worktree remove og oppgi banen til mappen. Ikke legg til --force: Hvis kopien inneholder ucommittede eller ikke-sporede filer, vil kommandoen nekte å slette den. Hvis kommandoen avviser forespørselen, kontrollerer du innholdet i mappen uten å deaktivere sikkerhetsmekanismen.

Når du oppdaterer Codex CLI, må du kontrollere versjonen på nytt med codex --version og gjenta kontrollen med git worktree list: Eksperimentelle flagg kan oppføre seg forskjellig mellom versjoner.

Flere ressurser og verktøy: Ailoot.

Flere detaljer

Spørsmål om denne veiledningen: Codex worktree: en separat arbeidskopi for en annen oppgave | Ailoot

Tar worktree nummer to med ulagrede eller ucommittede endringer?

Nei. I CLI-versjonen her starter det fra kilde-repositoryets HEAD-commit. Ucommittede endringer og nye filer blir i originalmappen. Lagring i editoren er ikke nok til overføring.

Er et rent detached worktree trygt å slette?

En ren mappe kan fortsatt ha commits uten navngitt gren. Bevar eller overfør commitene først, kontroller at ingen økt bruker worktreet og bruk vanlig Git-worktree-fjerning uten å tvinge forbi vern.

Alle artikler