Worktrees resolve to different project IDs due to per-worktree cache lookup #16995

Activity

1. github-actions

   assigned

   rekram1-node

   on Mar 11, 2026
2. github-actions

   added

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   on Mar 11, 2026
3. github-actions commented on Mar 11, 2026

   

   github-actionsBot

   on Mar 11, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Git worktrees + stash can cause projectID mismatch (sessions 404 across sandboxes) #12726: Describes the exact same root cause — worktree .git file causes per-worktree cache lookup, fallback git rev-list --max-parents=0 --all can return different root commits (e.g. due to stash), leading to mismatched project IDs and missing sessions. The proposed fix (use git rev-parse --git-common-dir) is identical.
   • Sessions gets mixed up across worktrees #13782: Sessions getting mixed up/shared across worktrees — a user-facing symptom of the same underlying issue.
4. afkent27 commented on Mar 11, 2026

   

   afkent27

   on Mar 11, 2026

   Author

   More actions

   Additional Findings

   After further investigation, the initial analysis was incomplete. The cache file approach (<gitdir>/opencode) cannot work in worktrees at all, regardless of where the file is placed.

   Root Cause (Corrected)

   In fromDirectory(), the code does:

   const dotgit = await matches.next().then((x) => x.value);  // finds .git entry
   let id = await Filesystem.readText(path.join(dotgit, "opencode"))  // reads cache

   Filesystem.up finds the .git entry by checking exists(). In a worktree, .git is a file (not a directory), containing gitdir: /path/to/.git/worktrees/<name>.

   path.join("/path/to/worktree/.git", "opencode") produces /path/to/worktree/.git/opencode — but .git is a file, so this path can never exist. The read always fails silently, and OpenCode falls back to git rev-list --max-parents=0 --all.

   Similarly, the write-back also fails silently:

   await Filesystem.write(path.join(dotgit, "opencode"), id).catch(() => { return; });

   So the cache is never read or written in worktrees. Every time OpenCode launches from a worktree, it recomputes the project ID from scratch.

   Why it produces wrong IDs

   git stash -u (stash with untracked files) creates orphan commits (zero parents) to store untracked file trees. git rev-list --max-parents=0 --all picks these up. Since the results are sorted lexicographically and the first entry is used as the project ID, any stash orphan that sorts before the real initial commit produces a different project ID.

   Suggested Fix

   Replace:

   const dotgit = await matches.next().then((x) => x.value);
   // ...
   let id = await Filesystem.readText(path.join(dotgit, "opencode"))

   With logic that resolves to the common git directory (which is always a real directory):

   const dotgit = await matches.next().then((x) => x.value);
   let sandbox = path.dirname(dotgit);
   // Resolve the actual git directory (handles worktrees where .git is a file)
   const commonDir = await git(["rev-parse", "--git-common-dir"], { cwd: sandbox })
       .then(async (result) => gitpath(sandbox, await result.text()))
       .catch(() => dotgit);
   let id = await Filesystem.readText(path.join(commonDir, "opencode"))

   And similarly for the write-back.

   Workaround

   A shell function wrapper that detects worktrees and runs opencode from the main repo root:

   opencode() {
       local git_common_dir
       git_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)
       if [ $? -ne 0 ]; then
           command opencode "$@"
           return
       fi
       local git_dir
       git_dir=$(git rev-parse --git-dir 2>/dev/null)
       if [ "$git_common_dir" != "$git_dir" ]; then
           local main_repo
           main_repo=$(dirname "$git_common_dir")
           command opencode "$main_repo" "$@"
       else
           command opencode "$@"
       fi
   }

   This passes the main repo root as the [project] positional argument so OpenCode finds the real .git directory (not the worktree .git file).
5. natewill commented on Mar 11, 2026

   

   natewill

   on Mar 11, 2026

   Contributor

   More actions

   #16684 fixes this
6. afkent27 commented on Mar 11, 2026

   

   afkent27

   on Mar 11, 2026

   Author

   More actions

   Better Workaround: Symlink Approach

   The previous workaround (redirecting to main repo root) has a critical flaw: OpenCode operates in the main repo directory instead of the worktree, so file edits and git operations happen in the wrong place.

   Better solution: Convert the worktree's .git file to a symlink pointing to the git worktree metadata directory (e.g., .git/worktrees/<name>/). This makes path.join(".git", "opencode") resolve through the symlink, while git operations continue to work correctly.

   # One-time conversion for existing worktrees:
   WORKTREE="/path/to/worktree"
   GITDIR=$(sed 's/gitdir: //' "$WORKTREE/.git")
   rm "$WORKTREE/.git"
   ln -s "$GITDIR" "$WORKTREE/.git"

   Shell wrapper that auto-converts on opencode launch:

   opencode() {
       local dotgit
       dotgit=$(git rev-parse --git-dir 2>/dev/null)
   
       if [ $? -eq 0 ]; then
           local toplevel
           toplevel=$(git rev-parse --show-toplevel 2>/dev/null)
           local gitfile="$toplevel/.git"
   
           # If .git is a regular file (worktree), convert to symlink
           if [ -f "$gitfile" ] && [ ! -L "$gitfile" ]; then
               local gitdir
               gitdir=$(sed 's/gitdir: //' "$gitfile")
               if [ -d "$gitdir" ]; then
                   rm "$gitfile"
                   ln -s "$gitdir" "$gitfile"
   
                   # Ensure the opencode cache exists in the target dir
                   local main_cache
                   main_cache=$(git rev-parse --git-common-dir 2>/dev/null)/opencode
                   if [ -f "$main_cache" ] && [ ! -f "$gitdir/opencode" ]; then
                       cp "$main_cache" "$gitdir/opencode"
                   fi
               fi
           fi
       fi
   
       command opencode "$@"
   }

   Tested: git status, branch, rev-parse, commit, push all work correctly through the symlink.
7. natewill commented on Mar 11, 2026

   

   natewill

   on Mar 11, 2026

   Contributor

   More actions

   All you have to do is call project.current with the directory name which calls fromDirectiory and resolves the project correctly
8. thdxr

   removed

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   on May 3, 2026
9. bashrusakh commented on Jun 24, 2026

   

   bashrusakh

   on Jun 24, 2026

   More actions

   Confirmed the same root cause in a worktree sandbox scenario. After a daemon restart, the project ID changed because the git remote URL was modified (fork). The new project ID caused fromDirectory() to create a separate project row and snapshot, splitting sessions across two projects. The original session was migrated via migrateProjectId, but existing sessions with the same title were forked (fork #1) under the new project.

   The current git.find() already uses --git-common-dir correctly for cache lookup — the cache itself is sound. The remaining gap is that fromDirectory() has no sandbox‑based project fallback: when the resolved ID differs from an existing project whose sandboxes already contain the directory, it still creates a new project.

   Opened a draft PR with a fix: if the directory is already a sandbox of another project, reuse its ID instead of creating a new one. This prevents the duplicate project and the spurious fork session.
10. github-actions commented on Aug 24, 2026

    

    github-actionsBot

    on Aug 24, 2026 – with GitHub Actions

    Contributor

    More actions

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
11. github-actions

    closed this as not plannedon Aug 24, 2026