anomalyco / anomalyco/opencode
Sessions disappear from the /sessions list after a local .git repo in the session's working directory is removed
@nexxeln is already working on this.
Since Sep 6, 2026.
- Dominant language
- TypeScript
- Stars
- 209k
- Forks
- 27.5k
- PR merge metrics
- PR metrics pending
Description
Description
After removing a project's .git directory, all existing sessions for that directory stop appearing in /sessions, even though the rows remain intact in opencode.db. Sessions created after the removal do appear (tagged with the global project), so history fragments across two project ids.
No data is deleted — only the list query stops matching.
Root cause (as of 1.18.29):
- Project identity is git-derived. When
git.repo.discoverfinds no repo,ProjectV2.resolvecollapses the directory to theglobalproject with noprevious(packages/core/src/project.ts:110-122). - Session migration only happens via
migrateProjectId(data.previous, projectID)infromDirectory(packages/opencode/src/project/project.ts:213-310). Thepreviousidentity cache is stored inside.git/opencode— deleting.gitdestroys it, so nogit-project-id → globalmigration ever fires and old sessions keep their staleproject_id. - The list query then hides them twice over:
listByProject(packages/opencode/src/session/session.ts:955-1008) always filtersproject_id = <current project>, and — with the collapsedworktreeof/— the TUI additionally filters bypath = <absolute directory>while old sessions store an emptypath. Either filter alone hides the sessions.
Expected:
old sessions remain visible — it is the same project directory, only the git metadata was removed.
Workaround (verified, script in comments):
Re-tag the orphaned sessions' project_id and path to match what their directory currently resolves to. A standalone repair script doing exactly this will be attached in comments (zero dependencies, runs with plain bun; dry-run by default, --apply --backup to write with a VACUUM INTO copy that backs up the current DB).
Related:
- #30683 (auto-closed after 60 days of inactivity; its closing bot comment invites a new issue if still relevant) — same bug family (
previouscache lost →migrateProjectIdno-op → stranded sessions) but a much rarer trigger: root-commit SHA drift after history rewrite plus cache loss (AV quarantine, WSL) while the repo still exists. Here the repo itself is gone: onerm -rf .gitis the entire trigger, and the identity collapses toglobal. - PR #30682 (fix for #30683, closed unmerged) — proposed a
project.worktreescan to recover orphaned projects. That scan would also recover this case (the old project row'sworktreestill matches the directory), but its author explicitly scoped out thepath = ""filter edge case inlistByProject— which is the second filter hiding these sessions after re-homing (global project →worktree=/→ TUI filters by absolutepath; old sessions store emptypath). A complete fix needs both legs: id recovery and path convergence (or a TUI guard). - #45133 (in-flight, fixes #23248) — repo rename/move: same identity resolving at a new path. Does not cover this case: path unchanged, identity changes (git id → global),
previouscache deleted with.git. - #5155 — the opposite direction (
git initorphans global sessions; fixed bymigrateFromGlobalatpackages/opencode/src/project/project.ts:291-298, which only matches the exact repo root).
Proposed fix:
ProjectDirectoriesalready records every directory associated with a project (project_directorytable). Add a reverse lookup inProjectV2.resolve: when no repo is found, consultproject_directoryfor the directory (deepest match) and resolve to that project's id instead ofglobal— the association row survives the.gitremoval.- TUI list-query guard: when the resolved
worktreeis the filesystem root, use project scope instead of apathfilter.
Plugins
None
OpenCode version
1.18.29
Steps to reproduce
- Have an existing session in a directory that is a git repository.
- rm -rf <YOUR_PROJECT_HERE>/.git
- Restart the server and re-attach or restart the OpenCode CLI client.
- Run /sessions.
Screenshot and/or share link
N/A
Operating System
MacOS 26.6.2, Ubuntu 24.04.4
Terminal
Terminal.app(MacOS), xterm-256color(Ubuntu)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.