Repository navigation
bug(core): empty git repos share the same "global" project ID, causing sessions to leak across unrelated directories #39773
Description
Description
When opencode runs inside a Git repository that has no commits and no remote, project resolution falls back to project_id = "global" for ALL such repos. This causes session.list to return sessions from completely unrelated directories.
For example, repos at:
/home/user/testing (empty repo)
/home/user/projeto-a (empty repo)
/home/user/Área de trabalho/teste_Engram (empty repo)
all get project_id = "global". When you open /sessions in any of them, you see sessions from all of them mixed together because listByProject filters only by project_id, not by directory.
Expected: each directory/repo should have its own project identity (or at least sessions should be scoped by directory when project_id is global).
Plugins
No response
OpenCode version
1.18.10
Steps to reproduce
mkdir -p /tmp/repo-a /tmp/repo-bcd /tmp/repo-a && git init && opencode# starts TUI- In another terminal:
cd /tmp/repo-b && git init && opencode - Create a session in repo-a (e.g. "session from A")
- Create a session in repo-b (e.g. "session from B")
- In either TUI, type /sessions
→ Both "session from A" and "session from B" appear
Screenshot and/or share link
No response
Operating System
Fedora Linux 44 (KDE Plasma Desktop Edition) x86_64
Terminal
Konsole
Activity
github-actions commentedon Jul 31, 2026
This issue might be a duplicate of existing issues. Please check:
project_id = 'global'across multiple directories, causing /sessions to list all sessions globally with no project scopingglobalID fallback as the root cause)These issues all stem from the same root cause in
Project.resolve: directories without a distinguishing git remote or root commit fall back toid = "global", causing session leakage across unrelated directories.github-actions commentedon Sep 29, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
Chudesnov commentedon Nov 7, 2026
Reproduced on Windows 11, OpenCode Desktop 2.0.26 — with conditions even weaker than "empty repo": a corrupted
.gittriggers the same fallback.Minimal conditions: git discovery succeeds, but all three identity sources fail — no remote (
exit 2), no cached.git/opencodemarker, no root commit (rev-parse -q --verify HEAD->exit 1). A mangled.git(HEAD -> ref: refs/heads/.invalid, noconfig, no refs) hits this exactly, as does any healthygit initwithout commits.Desktop symptom: the directory gets adopted into the pre-existing
globalproject, so "Add project" opens whichever directory first claimedglobal's worktree — under that directory's name. Giving the repo a root commit resolves identity correctly.Chudesnov commentedon Nov 7, 2026
Follow-up, since it affects what a fix must cover: repairing the repo is not sufficient to recover a directory that already squatted on
global.After giving the repo a remote and a root commit, the desktop kept resolving "Add project" to
globalacross an app restart. Two things keep the stale binding alive: stored session rows (session_v2.project_id = 'global'— instances bootstrap from the stored project instead of re-resolving), and the service's per-directory location cache (GET /api/locationstill returnedid:"global"for a fully valid repo).POST /api/location/reloadflushed it: the next resolve created the correct remote-derived project, and the projector migrated the affected session out ofglobalautomatically. So the fix needs a re-resolution/migration path for already-squatted directories, not just correct new resolves.(Correction to my comment above: desktop version is 2.2.6, not 2.0.26 — the updater state file was stale;
main.logself-reports 2.2.6.)mahammedmahieousman commentedon Nov 7, 2026