project: adding a git remote changes the project ID and hides every earlier session #57985

Activity

1. opencode-agent commented on Oct 22, 2026

   

   opencode-agentBot

   on Oct 22, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the clear report and repro. I could reproduce this on 2.0.32, and it still happens on the latest dev (248bfbe11):

   1. git init and an empty root commit in a fresh directory.
   2. opencode api session.create --standalone ...: the session gets a project ID based on the root commit, and opencode session list --standalone lists it.
   3. git remote add origin [email protected]:example/repro.git.
   4. opencode session list --standalone now prints nothing. The repo resolves to a new project ID based on the remote, and the earlier session stays under the old one.

   The script below reproduces it.

   I haven't tested a fix, but the cause looks like this: once a remote exists, the remote-based ID replaces the existing one. The step that moves sessions to a directory's new identity only covers sessions in the global project and in a project ID read from a legacy .git/opencode file, which v2 never writes. Sessions under the root-commit project aren't moved, and neither are the permission rules. Your SQL workaround is the only way to recover them for now.

   Reproduction script (repro.sh)

   #!/usr/bin/env bash
   # Reproduces #57985: adding a git remote changes the project ID and hides earlier sessions.
   # Usage: ./repro.sh            (uses `opencode` from PATH)
   #        From source (the --standalone child is re-spawned via bun, so pass flags via BUN_OPTIONS):
   #        BUN_OPTIONS="--conditions=browser --preload=<repo>/packages/tui/node_modules/@opentui/solid/scripts/preload.js" \
   #          OC="bun <repo>/packages/cli/src/index.ts" ./repro.sh
   set -u
   OC=${OC:-opencode}
   export HOME=$(mktemp -d)            # isolated data dir / database
   export XDG_DATA_HOME=$HOME/.local/share XDG_CONFIG_HOME=$HOME/.config XDG_STATE_HOME=$HOME/.local/state XDG_CACHE_HOME=$HOME/.cache
   DIR=$(mktemp -d)/repro
   mkdir -p "$DIR" && cd "$DIR"
   git init -q && git -c user.email=a@b -c user.name=a commit -q --allow-empty -m root
   echo "== version: $($OC --version)"
   echo "== create session before remote"
   $OC api session.create --standalone --data '{"title":"created before the remote"}'
   echo; echo "== session list (before remote)"
   $OC session list --standalone
   git remote add origin [email protected]:example/repro.git
   echo "== session list (after git remote add)"
   $OC session list --standalone
   echo "== (end; empty list above = bug)"
   DB=$(find "$HOME" -name '*.db' 2>/dev/null | head -1)
   if [ -n "$DB" ] && command -v sqlite3 >/dev/null; then
     echo "== projects:"; sqlite3 "$DB" "select id, worktree, vcs from project"
     echo "== sessions:"; sqlite3 "$DB" "select id, project_id, title from session_v2"
   fi

   Run it: bash repro.sh
2. opencode-agent

   added

   reproduced

   on Oct 22, 2026
3. loofahss commented on Oct 23, 2026

   

   loofahss

   on Oct 23, 2026

   More actions

   Adjacent data point on 2.0.32: when a plain directory becomes a git repo, the carry-over does
   work — including for sessions in sub-directories — so whatever strands sessions in the remote case
   looks narrower than "only sessions in the global project are moved".

   Isolated repro (own XDG_DATA_HOME/XDG_CONFIG_HOME, no plugins):

   mkdir -p work/parent/sub
   (cd work/parent/sub && opencode api session.create --standalone --data '{"title":"sub-before-git"}')
   (cd work/parent     && opencode api session.create --standalone --data '{"title":"parent-before-git"}')
   cd work/parent && git init -q && git commit -q --allow-empty -m root
   opencode session list --standalone        # from parent
   (cd sub && opencode session list --standalone)
   

   Before git init the two sessions get path-based project ids (007f4a82… for parent,
   5c825dbb… for parent/sub), each listed in its own directory. After git init + root commit
   (cd4c6bb8…), both sessions have session_v2.project_id = cd4c6bb8… and both are listed from
   either directory. The two old path-based project rows are still present (not deleted), so this
   does not look like the migrateProjectId old→new path either.

   So sessions do follow a directory's new identity even when their old project id is not global.
   If that is the same code meant to cover the remote case, what differs there?

   One unrelated thing noticed in the same run, in case it is known: project_directory stays empty
   in the repro database — no row for the newly created git project. On the machine I upgraded, the
   newest row in that table predates the 2.0.32 upgrade, so nothing appears to write it any more.
4. holny commented on Oct 24, 2026

   

   holny

   on Oct 24, 2026

   Contributor

   More actions

   Reproduced the same switch on the latest dev. In packages/core/src/project.ts the resolve path ranks the remote URL ahead of the cached previous ID (remote(repo) ?? previous ?? rootCommit(repo)), so the first resolution after git remote add mints a second project row and strands every session under the root-commit ID.

   Happy to take this: I'd flip the order so an already-resolved repo keeps its ID (fresh clones still get the remote-derived one), plus a regression test. PR within a day or two.
5. argszero commented on Oct 29, 2026

   

   argszero

   on Oct 29, 2026

   Contributor

   More actions

   There is a pull request open for this defect: #59946, which closes #59371 — the same problem reported from the session list side.

   What it does: packages/core/src/session/store.ts lists sessions for every project row that shares the caller's worktree, instead of only the single row it was handed. Your sessions were never deleted; they are filed under the pre-remote row, and the query only ever asked about one of the folder's rows. Matching by worktree makes them visible again for repositories already in this state, not only for ones created after the fix.

   How it was proven, red before green: with two project rows on one worktree and one on another worktree, listing for the newer row returned only its own session before the change, and both sessions after it, while the other worktree's session stayed out. The change also carries a regression test for the global row, which must never be matched: its worktree is whichever commitless repository resolved to it first, so matching it cross-listed unrelated directories — that case fails without the exclusion and passes with it. opencodejr re-ran the remote-added reproduction from source and confirmed both sessions are listed with the change and only the post-remote one without.

   What it does not cover, so this is not a complete fix of the underlying cause:

   • It is a read-side change. The sessions keep the stale project id they were written with; nothing re-files them. The migration layer where identity is meant to change hands is fix(core): move sessions to the remote-derived project id when a remote is added later #58668, still open, and if that merges this becomes redundant rather than wrong.
   • Other readers that filter by a single project id — session/stats.ts, for one — still see the narrow view.
   • Part B of sessions: folder-scoped list hides sessions when a worktree owns duplicate project rows #59371 (/api/location returning the service's start directory rather than the caller's cwd) is a different layer and is deliberately not in this change.

   I verified the branch still applies cleanly to today's dev (7ab721a97f38), and that project.ts and session/projector.ts are untouched since this was reproduced, so the defect is still live.
6. gaojunran commented on Oct 31, 2026

   

   gaojunran

   on Oct 31, 2026

   More actions

   A second consequence of the same ID switch, filed separately since it is an API-level failure and also hits sessions that stay visible: #60857 — /session/:id/diff returns HTTP 500 Snapshot.Error: fatal: bad object <tree> for every turn captured before the ID change, because the snapshot store is keyed by project.id (snapshot.ts:96) and never follows the new ID. Verified with a two-step repro on 2.1.2 (diff works, git remote add origin, same call 500s). Snapshots from v1-era sessions that were re-projected onto the new project ID are affected too, even though those sessions still appear in the list.