The verdict

When an agent edits code, the first safety question is not whether it is clever. It is whether it will write into the directory a person is actively editing. Git worktrees solve directory isolation: multiple working directories can attach to one repository, each with its own HEAD and index while sharing objects and most refs. That makes them useful for scheduled runs, candidate branches, and parallel experiments. It does not make them a container, a permission system, or a network boundary.

What a worktree actually separates

Git’s documentation describes a linked worktree as another working tree associated with the same repository. Its working directory, HEAD, and index are independent; repository objects and most refs remain shared. This explains the apparent contradiction: an agent can edit a separate directory without overwriting uncommitted files elsewhere, while both worktrees still see the same commits and remote branches.

That is exactly the useful boundary for a content pipeline. The main checkout can remain available for human work while a scheduled task creates a bot branch, renders content, and runs tests in a temporary worktree. Whether the result can enter main still belongs to CI, branch policy, and fast-forward rules.

A minimal operating model

git fetch --prune origin
git worktree add -b codex/content-run /tmp/content-run origin/main
git -C /tmp/content-run status --short --branch
git -C /tmp/content-run rev-parse --git-common-dir

At the end, save the commit, test result, and receipt before handling the worktree. Do not run worktree remove against an unconfirmed path. If a directory is deleted by hand, Git’s administrative files can remain until a later prune; git worktree prune is repository maintenance, not a production rollback.

Why it is not a sandbox

A worktree does not restrict a process from reading other paths, making network calls, or using GitHub or Cloudflare permissions. An agent with write access can still run a release script or update shared refs. The real boundary has to combine minimal credentials, an allowed command surface, state-branch compare-and-swap, an exact public manifest, and a production smoke test.

Nor does a worktree define data retention. A draft, build artifact, or log copied into the temporary directory may still contain sensitive material. Cleanup, ignore rules, and the fields allowed in a receipt need their own policy.

Four gates for agent worktrees

  1. Confirm the base before creating the worktree.
  2. Keep the diff limited to the candidate; do not fold in an unrelated refactor.
  3. Before committing, run the repository checks and compute an exact route delta.
  4. After production, record the observed result in the one durable state owner; never treat an ignored local file as publication proof.

These gates connect Git’s directory isolation to a release protocol. They do not prove that the agent’s code is correct. They make mistakes attributable and recoverable.

When it is worth using

Scheduled content generation, dependency updates, automated fixes, and version comparisons are good worktree candidates. A short task in a clean checkout can be simpler without one. Once a run crosses a wait, CI, or an external release, the audit value of a separate worktree increases quickly.

Evidence boundary

Git documents the linked-directory, shared-ref, and prune semantics; OpenAI documents choosing background worktrees for Scheduled Tasks. The bot branch, state branch, and release gates described here are Omnihex’s application of those primitives, not a Git security guarantee for agents.