Grok Build + Git Worktrees

Best practices for working with Grok Build, especially when using worktrees and agentic workflows

The Core Idea

Grok Build has built-in support for managing Git worktrees. This is one of its most powerful (and under-appreciated) features when you're doing serious work with agents, multiple projects, or following patterns like the "Chief of Staff" workflow.

The key insight is this:

Your normal GitHub clone should stay clean and stable.

Grok Build should do most of its work inside its own managed worktree.

Recommended Setup

1. Keep Your Main Clone Clean

Continue using your normal folder (e.g. ~/Documents/GitHub/mikesblogdesign.com) as your source of truth. This is where you do final reviews, pushes, and stable work.

2. Let Grok Manage Its Own Worktree

When you open a project through Grok Build, it creates and tracks a worktree under ~/.grok/worktrees/. Do the majority of your editing and agent work here.

3. Use a Symlink for Convenience

Create an easy path like ~/mikesblogdesign-grok that points to the Grok worktree. This makes it feel like "the" place you work on the project when using Grok.

Best Practices

Daily Workflow

  • Normal development → Work inside the Grok-managed worktree (~/your-project-grok)
  • Final commits / PRs → Switch to your main GitHub clone to review and push (or push directly from the worktree if you're comfortable)
  • Agent / long-running tasks → Always run these inside a Grok worktree so they don't pollute your main checkout
  • Experiments → Create additional worktrees (e.g. grok-experiment-foo) for risky or parallel work

Git Commands That Matter

# See all your worktrees (including Grok's)
git worktree list

# From inside a Grok worktree, this shows both your main clone + the Grok one
git worktree list

# Create a new experimental worktree
git worktree add ../experiment-feature -b experiment/feature-x

Using the grok worktree Commands

Grok Build has its own worktree management layer on top of Git:

grok worktree list
grok worktree show <id>
grok worktree rm <id>
grok worktree gc          # clean up stale ones
grok worktree db rebuild  # resync the database

Use these instead of raw Git commands when you're inside a Grok session.

Can Grok Build Act as a Chief of Staff?

This is the question that started a lot of this exploration.

Grok Build Strengths

  • Native worktree management and tracking
  • Can spawn and manage multiple worktrees
  • Session isolation is built-in
  • You can build custom agents on top of it
  • Works very well for "one persistent brain + many tasks"

Where Codex (currently) Wins

  • Deeper automatic integration between the AI and worktrees
  • The "persistent thread as Chief of Staff" experience feels more native
  • Less manual orchestration required

Bottom line:

You can build a very effective Chief of Staff system using Grok Build + worktrees right now (this site is proof of concept). However, it currently requires more manual setup and discipline than the vision described in the original Codex tweet.

The sweet spot for many people right now is:

  • Use Grok Build for serious, long-running, agentic work on projects
  • Use Codex when you want the most seamless "one persistent Chief of Staff thread" experience
  • Use both (they're not mutually exclusive)

Recommended Mental Model

Think of it like this:

Your normal GitHub folder = Your stable, long-term source of truth

Grok worktree = Your active workshop + where agents live and experiment

Additional worktrees = Temporary benches for specific tasks or experiments

This separation is what makes the Chief of Staff pattern actually work at scale.

Want help setting up this workflow for your own projects?

Let's Talk About It →