anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[BUG]: Project ID collision when repos cloned from same source share sessions #4108

New Issue
Open
opened 2026-02-16 17:42:39 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 17:42:39 -05:00
Owner
Copy Link
Copy Source

Originally created by @bcheung on GitHub (Jan 2, 2026).

Originally assigned to: @thdxr on GitHub.

Repos cloned from the same source share the same root commit hash, causing them to share sessions unexpectedly. Opening opencode in either repo shows sessions from both.

Affected workflows

  • Cloned templates (e.g., create-react-app, Next.js starters)
  • Forks
  • Any "clone and change origin" workflow

Reproduction

#!/bin/bash
set -e

WORKDIR=$(mktemp -d)
cd "$WORKDIR"

# Create template repo and clone it twice
mkdir template && cd template
git init -q && echo "template" > README.md && git add . && git commit -qm "init"
cd "$WORKDIR"
git clone -q template clone-a
git clone -q template clone-b

# Run opencode in each
(cd "$WORKDIR/clone-a" && opencode run "respond with only: session from clone-a")
(cd "$WORKDIR/clone-b" && opencode run "respond with only: session from clone-b")

# Verify collision
echo "clone-a project ID: $(cat "$WORKDIR/clone-a/.git/opencode")"
echo "clone-b project ID: $(cat "$WORKDIR/clone-b/.git/opencode")"
# Both are identical - opening opencode in either shows sessions from both

Root cause

Project ID is derived from the first root commit hash:

https://github.com/anomalyco/opencode/blob/038cff4a93bb39238534898b4790229773c4ff22/packages/opencode/src/project/project.ts#L57-L72

Related

  • #5638 - Same root cause but for git worktrees. PR #5647 fixes worktrees by adding worktree hash, but cloned repos aren't worktrees so they still collide.

Notes on solution

The fix probably needs to be conditional:

  • Worktree → Share project ID with main repo (current behavior is correct for this case)
  • Git repo (not worktree) → Need deterministic unique ID that doesn't collide across clones. Root commit alone isn't sufficient. Options: include absolute path in hash, or remote origin URL, or generate UUID on first run.
  • Not a git repo → Could use absolute path

Key insight: PR #5647 correctly handles worktrees. This issue is specifically about the non-worktree clone scenario.

Side note: worktree caching

In git worktrees, .git is a file (not directory) pointing to .git/worktrees/<name>/. The current cache write to .git/opencode fails silently. Depending on the solution chosen here, this silent failure may cause issues if the fix relies on persisting something to that file.

https://github.com/anomalyco/opencode/blob/038cff4a93bb39238534898b4790229773c4ff22/packages/opencode/src/project/project.ts#L53-L56

Originally created by @bcheung on GitHub (Jan 2, 2026). Originally assigned to: @thdxr on GitHub. Repos cloned from the same source share the same root commit hash, causing them to share sessions unexpectedly. Opening opencode in either repo shows sessions from both. ## Affected workflows - Cloned templates (e.g., `create-react-app`, Next.js starters) - Forks - Any "clone and change origin" workflow ## Reproduction ```bash #!/bin/bash set -e WORKDIR=$(mktemp -d) cd "$WORKDIR" # Create template repo and clone it twice mkdir template && cd template git init -q && echo "template" > README.md && git add . && git commit -qm "init" cd "$WORKDIR" git clone -q template clone-a git clone -q template clone-b # Run opencode in each (cd "$WORKDIR/clone-a" && opencode run "respond with only: session from clone-a") (cd "$WORKDIR/clone-b" && opencode run "respond with only: session from clone-b") # Verify collision echo "clone-a project ID: $(cat "$WORKDIR/clone-a/.git/opencode")" echo "clone-b project ID: $(cat "$WORKDIR/clone-b/.git/opencode")" # Both are identical - opening opencode in either shows sessions from both ``` ## Root cause Project ID is derived from the first root commit hash: https://github.com/anomalyco/opencode/blob/038cff4a93bb39238534898b4790229773c4ff22/packages/opencode/src/project/project.ts#L57-L72 ## Related - #5638 - Same root cause but for git worktrees. PR #5647 fixes worktrees by adding worktree hash, but cloned repos aren't worktrees so they still collide. ## Notes on solution The fix probably needs to be conditional: - **Worktree** → Share project ID with main repo (current behavior is correct for this case) - **Git repo (not worktree)** → Need deterministic unique ID that doesn't collide across clones. Root commit alone isn't sufficient. Options: include absolute path in hash, or remote origin URL, or generate UUID on first run. - **Not a git repo** → Could use absolute path Key insight: PR #5647 correctly handles worktrees. This issue is specifically about the non-worktree clone scenario. ## Side note: worktree caching In git worktrees, `.git` is a file (not directory) pointing to `.git/worktrees/<name>/`. The current cache write to `.git/opencode` fails silently. Depending on the solution chosen here, this silent failure may cause issues if the fix relies on persisting something to that file. https://github.com/anomalyco/opencode/blob/038cff4a93bb39238534898b4790229773c4ff22/packages/opencode/src/project/project.ts#L53-L56
yindo commented 2026-02-16 17:42:39 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 2, 2026):

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

  • #5638: Desktop app: opening multiple git worktrees from the same repo replaces existing project - same root cause (project ID derived from root commit hash)
  • #4656: Executing run command in worktree reports 'file already exists' error - related worktree handling issue mentioned in the "Side note: worktree caching" section

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 2, 2026): This issue might be a duplicate of existing issues. Please check: - #5638: Desktop app: opening multiple git worktrees from the same repo replaces existing project - same root cause (project ID derived from root commit hash) - #4656: Executing run command in worktree reports 'file already exists' error - related worktree handling issue mentioned in the "Side note: worktree caching" section Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:42:39 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Jan 2, 2026):

For worktree stuff did u see the lines of code underneath that? We handle the case that it fails?

@rekram1-node commented on GitHub (Jan 2, 2026): For worktree stuff did u see the lines of code underneath that? We handle the case that it fails?
yindo commented 2026-02-16 17:42:39 -05:00
Author
Owner
Copy Link
Copy Source

@bcheung commented on GitHub (Jan 3, 2026):

the issue is worktree/.git is a file rather than a folder so the next bit of logic that tries to write the project id also fails silently cause there's no promise handling: https://github.com/anomalyco/opencode/blob/038cff4a93bb39238534898b4790229773c4ff22/packages/opencode/src/project/project.ts#L71

this is one line repro script that will emulate what is going on:

cd $(mktemp -d) && git init -q main && git -C main commit --allow-empty -qm "init" && git -C main worktree add ../wt -b t -q && echo ".git is a file:" && cat wt/.git && echo "" && echo "Write fails:" && bun -e "await Bun.file('$(pwd)/wt/.git/opencode').write('x')"

Think what you are looking for is to check and write to /path/to/project/.git/worktrees/my-worktree/opencode

@bcheung commented on GitHub (Jan 3, 2026): the issue is worktree/.git is a file rather than a folder so the next bit of logic that tries to write the project id also fails silently cause there's no promise handling: https://github.com/anomalyco/opencode/blob/038cff4a93bb39238534898b4790229773c4ff22/packages/opencode/src/project/project.ts#L71 this is one line repro script that will emulate what is going on: ``` cd $(mktemp -d) && git init -q main && git -C main commit --allow-empty -qm "init" && git -C main worktree add ../wt -b t -q && echo ".git is a file:" && cat wt/.git && echo "" && echo "Write fails:" && bun -e "await Bun.file('$(pwd)/wt/.git/opencode').write('x')" ``` Think what you are looking for is to check and write to `/path/to/project/.git/worktrees/my-worktree/opencode`
yindo commented 2026-02-16 17:42:39 -05:00
Author
Owner
Copy Link
Copy Source

@colinmollenhour commented on GitHub (Jan 29, 2026):

Would that explain this bug where the pwd of my session doesn't match the project I selected? It affects the Web mode, but not the TUI.

Image
@colinmollenhour commented on GitHub (Jan 29, 2026): Would that explain this bug where the pwd of my session doesn't match the project I selected? It affects the Web mode, but not the TUI. <img width="1413" height="566" alt="Image" src="https://github.com/user-attachments/assets/0d9a034a-5959-4e3d-8fed-98d242d63d9b" />
yindo commented 2026-02-16 17:42:39 -05:00
Author
Owner
Copy Link
Copy Source

@rachidbch commented on GitHub (Feb 1, 2026):

I don't delete the "issue" below (below the ***) because it may help another new comer to opencode.
But the "quick fix" is pretty simple, you just have to use opencode session management to create a (at least) a session by worktree.

*** > Original reported problem

For me I have a /main/repo/ and created a git worktree in /wortree/repo/ to work in parallel on both with opencode, but both folders share the same opencode conversation, which defeats the use of worktrees for parallel work...
Am I doing something wrong (I'm new to opencode, had no problem on this with claude-code) ?

Does anyone has a quick fix to force opencode to use two separate conversations (or sessions as I presume a conversation is attached to a session) ?

Environment: WSL2/Windows11, opencode version 1.1.48

@rachidbch commented on GitHub (Feb 1, 2026): I don't delete the "issue" below (below the ***) because it may help another new comer to opencode. But the "quick fix" is pretty simple, you just have to use opencode session management to create a (at least) a session by worktree. *** > Original reported problem For me I have a /main/repo/ and created a git worktree in /wortree/repo/ to work in parallel on both with opencode, but *both folders share the same opencode conversation*, which defeats the use of worktrees for parallel work... Am I doing something wrong (I'm new to opencode, had no problem on this with claude-code) ? Does anyone has a quick fix to force opencode to use two separate conversations (or sessions as I presume a conversation is attached to a session) ? Environment: WSL2/Windows11, opencode version 1.1.48
yindo commented 2026-02-16 17:42:39 -05:00
Author
Owner
Copy Link
Copy Source

@colinmollenhour commented on GitHub (Feb 1, 2026):

As far as I know there is not a way to change the pwd of a TUI session, although I do think that would be useful. E.g. to be able to say "Read these plans, create a worktree, make that worktree the active pwd and implement the plans" from inside a TUI session. Is that what you mean?

@colinmollenhour commented on GitHub (Feb 1, 2026): As far as I know there is not a way to change the pwd of a TUI session, although I do think that would be useful. E.g. to be able to say "Read these plans, create a worktree, make that worktree the active pwd and implement the plans" from inside a TUI session. Is that what you mean?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4108
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?