Given my first experience with GH Stacks, I found myself hitting a proverbial wall when trying to incorporate it into my worktree-based workflow.

With a single repository checkout, the quick start documentation describes a straightforward and pleasant experience. However, things become much less smooth when using Git worktrees.

From what I can tell, the GH Stacks metadata is scoped to the worktree where the stack was created, rather than to the repository as a whole. As a result, other worktrees in the same repository cannot see or operate on that stack.

My primary use case is splitting a larger feature into multiple dependent PRs. While an AI agent is implementing or troubleshooting the first PR, I’d like to begin working on the next piece in a separate worktree. Unfortunately, because Git prevents a branch from being checked out in multiple worktrees simultaneously, any gh stack rebase or similar operation requires me to pause work, detach the affected branches from their worktrees, perform the stack operation, and then restore the worktrees before I can continue.

I may be missing an intended workflow, but this feels like an unnecessary limitation of an otherwise excellent tool. It seems these issues could largely disappear if the GH Stacks metadata lived at the repository level (for example, in the shared Git directory used by all worktrees), allowing the gh stack CLI to resolve and operate on the same stack regardless of which worktree it is invoked from, similar to how Git itself treats worktree-aware repository state.