Is Git Stash Shared Between Worktrees?

Yes, Git stash is shared between worktrees attached to the same repository. One agent can pop a stash created by another agent: worktrees share most refs, including refs/stash, and a plain git stash pop selects the latest stash entry. The files and index in each worktree remain separate, but the stash list does not. Give agents separate branches and worktrees for unfinished changes; use a named stash only when an agent needs to clear its own worktree temporarily.

What is shared, and what stays separate?

A linked worktree has its own checked-out files, index, and HEAD. An agent editing a file in one worktree does not edit the copy in another. The worktrees still belong to one Git repository, whose ordinary refs are shared. refs/stash is one of those refs.

A stash records changes from the worktree where it was created. It does not carry a rule that limits where those changes may be restored. If an agent in another worktree runs git stash pop, Git tries to apply the newest entry to that agent’s current files and removes the entry if the application succeeds. A conflicting pop leaves the entry in the stash list, but still requires the conflicts to be handled. Either outcome can interrupt the wrong agent’s task.

Item	Scope	Consequence for agents
Checked-out files and index	Each worktree	Agents can edit and stage their own copies.
HEAD	Each worktree	Agents can have different branches checked out.
refs/stash and its list	Repository	A stash made in either worktree appears in both.

The distinction matters when an agent interprets stash@{0} as “my last stash.” It means the newest entry in the repository’s stash list. Another agent’s git stash push can make a different entry newest. The labels stash@{0} and stash@{1} describe positions, not owners, and those positions can change as entries are added or removed.

Keep active changes in each agent’s worktree

For example, suppose one agent owns an authentication task and another owns a search task. Create a separate branch and linked worktree for each:

git worktree add -b agent/auth ../agent-auth
git worktree add -b agent/search ../agent-search
git worktree list

Run each agent from its assigned directory. Each can leave edits unfinished there while the other continues. There is no need to stash merely to switch your attention between agents: the unfinished files remain in their respective worktrees. See how Git worktrees support agent isolation for the broader branch and directory setup.

A worktree is a workspace, not a private stash namespace. Tell agents which directory and branch they own, and avoid giving them an instruction such as “pop your stash” unless the intended entry has been identified. Branch names help identify work, but a stash description’s branch name is context, not an access control mechanism.

For a checkpoint that should travel with an agent’s branch, make a commit. Git adds selected files to the index, and a commit records the index on the current branch. Review the selected paths before committing; an agent’s worktree can contain unrelated generated or local files.

cd ../agent-auth
git status
git add -- src/auth tests/auth
git commit -m 'Checkpoint auth changes'

Here, src/auth and tests/auth are example paths; choose paths that belong to the actual task. A checkpoint commit gives the unfinished work a branch location that another agent will not accidentally select with a bare git stash pop. It also makes the handoff explicit when you later merge work from parallel agents.

When a stash is useful, name and inspect it

A stash is useful when an agent needs a clean worktree briefly but is not ready to make a checkpoint commit. Create it from the agent’s own worktree with a message that identifies the task:

cd ../agent-auth
git status
git stash push -u -m 'agent/auth: validation in progress'
git stash list

-m supplies a description. -u includes untracked files as well as the changes normally saved by a stash. Without -u, newly created files may remain in the worktree. --all goes further and includes ignored files; use it only when those files are genuinely part of what you intend to put away. A stash message makes an entry easier to find, but Git still stores it in the shared list.

You can narrow a stash to particular paths if the worktree contains several unrelated changes:

git stash push -u -m 'agent/auth: form draft' -- src/auth/forms tests/auth/forms

The -- separates options from the path arguments. A path-limited push saves and rolls back matching paths while leaving other paths alone. Check git status afterward to see what remains. Status distinguishes staged, unstaged, and untracked changes, so it is also the place to check what you are about to put away.

Before restoring anything, inspect the shared list and the candidate entry:

git stash list
git stash show -p -u 'stash@{1}'

This example inspects the second entry shown by the list; choose the entry that actually matches the task. -p displays a patch, and -u includes any untracked files saved in the entry. Read the paths and changes, not just the message. A label can be mistaken or reused.

Restore an identified entry without consuming it

When agents may create stashes concurrently, pause stash writes while you identify an entry. Then capture its commit ID before restoring it:

stash_oid=$(git rev-parse --verify 'stash@{1}^{commit}')
git stash apply "$stash_oid"
git status

git rev-parse --verify resolves the selected revision to an object ID. The ID identifies that stash commit even if a later push changes the stash@{n} positions. git stash apply accepts a stash commit and leaves the shared stash entry in place. Inspect the resulting files and resolve any conflicts before deciding whether the entry can be dropped. Capturing an ID does not establish ownership by itself; inspect the entry before applying it.

Run apply from the worktree that should receive the changes. Git applies the saved changes over that worktree’s current state, so differing files can conflict. If restoring the staged state matters, git stash apply --index "$stash_oid" also attempts to reinstate the index, but that attempt can fail when conflicts occupy the index.

A direct git stash pop 'stash@{1}' is appropriate only when you have identified the entry, have coordinated against concurrent stash changes, and intend to remove it on success. The argument chooses a specific position at the time the command runs; it does not make that position stable for later commands. For agent handoffs, apply is usually easier to review because it preserves the saved entry while you check the result.

If an agent used the wrong stash

First, stop further stash pushes, pops, and drops while you identify the entry and inspect the receiving worktree. Run git status there and git stash list from either worktree. A successful pop removes its entry from the list; a pop that failed with conflicts leaves the entry listed. Do not use git stash clear to tidy up: it removes all entries in this repository’s stash list, including entries other agents may need.

There is no universal command to undo a mistaken application safely when the receiving worktree already had edits. Review the affected paths and preserve any preexisting work before removing changes. If the original branch has moved enough that a valid stash conflicts when applied, git stash branch can create and check out a branch at the commit on which the stash was created, then apply the changes there. For example, after identifying the entry, run this from a clean worktree; agent/auth-stash-recovery is an example branch name:

git stash branch agent/auth-stash-recovery 'stash@{1}'

If restoration succeeds, Git drops an entry specified as stash@{n} from the shared stash list. Confirm that the entry belongs to the task and coordinate with its owner before using this command.

Where Parallel Code fits

Parallel Code is our free, open-source desktop app for macOS and Linux. It runs several AI coding agents in parallel, each isolated in its own Git worktree, and provides a diff-first review surface. That worktree separation keeps active files apart; the repository’s Git stash remains shared, so the stash practices above still apply.

Frequently asked questions

Does each Git worktree have its own stash?

No. Linked worktrees have separate files and indexes, but the ordinary refs/stash reference is shared by the repository. A stash created in one worktree appears in git stash list from another worktree attached to it.

Can one agent pop another agent’s stash?

Yes. Without an argument, git stash pop takes the newest shared entry, regardless of which worktree created it. Inspect the entry and name it explicitly, or use git stash apply with its commit ID when you want to keep the entry during review.

Does a stash message make an entry private?

No. git stash push -m adds a description that helps people identify the entry; it does not restrict access to a worktree or agent. Keep the agent’s unfinished files in its own worktree, or record a checkpoint on its branch when the work should have a durable task-specific location.

What happens if applying a stash conflicts?

The receiving worktree needs conflict resolution. A conflicting git stash pop does not remove the entry from the shared list, while git stash apply keeps the entry regardless of whether application succeeds. Check the receiving worktree and the stash list before trying another restore.