A Codex Worktree's Result Depends on Files Git Doesn't Carry
Codex ran your ablation in a separate worktree and reports a two-point gain. Before that number goes in a results table, to a teammate or into the trash with the worktree, check what it depended on that Git does not carry.
OpenAI's worktree guide sets out what a Codex worktree holds. Codex creates it in $CODEX_HOME/worktrees, starting from the HEAD commit of the branch you selected, so tracked files are present. Files covered by .gitignore are not, unless they match a pattern in .worktreeinclude. Codex keeps your 15 most recent Codex-managed worktrees by default and saves a snapshot before it deletes one, which you restore by reopening the chat.
That leaves two gaps. Research repos ignore exactly the files that decide a result: data/, cached tokenized shards, local checkpoints, the .env that picks the model endpoint. A worktree missing them may load a default dataset, rebuild a cache with other settings or call another endpoint, and still print a clean number. And the snapshot protects the code while tying the evidence to a chat. A teammate, or you in six months, will look in the repo.
Before you compare numbers, run this in the worktree and in your main checkout:
git rev-parse HEAD
sha256sum data/eval.jsonl configs/ablation.yaml
git status --ignored --shortThe commit should be the one you meant, the hashes should match, and the ignored files the eval reads (lines starting !!) should be present in both. If they differ, the two-point gain may measure the inputs rather than the change.
Before you hand it off or remove the worktree, write a short record into the repo, such as results/label-smoothing.md, instead of pointing someone at 200 turns of chat:
- the commit, and the branch or diff;
- the exact command, config, seed and data version;
- the metric with n and an interval, next to the baseline on the same items;
- every ignored file the run read, by name and hash;
- for an idea you are dropping, one sentence on why.
Add an ignored file's pattern to .worktreeinclude only if it is safe to copy. Never copy credentials that way; name the secret the run needs. Link to bulk data instead of committing it. A failed idea needs the record most, because its worktree is the first one you will want to delete, and a negative result is expensive to rediscover.
The check. Open a fresh worktree from the recorded commit, give it only what the record names, run the command and compare the metric. The same number (or, for a sampled run, one inside the interval you reported) means the record is complete. A different number means a dependency is missing, and finding it now costs less than finding it after someone builds on the result.
A worktree also leaves everything outside the repo shared: two can write to the same tracker project or results bucket. Worktrees separate files, not experiments covers that gap. Chapter 16 treats an eval as a measurement that starts with knowing exactly what went in, and Chapter 20 treats an honest report, including what failed, as part of the work.
