Desktop app 1.1.15: cannot create a second Local (branch) session while one is running — "This project already has an active Local workspace"
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Shell
- Sterne
- 11.2k
- Forks
- 1.9k
- Ø Merge
- 14 Std. 16 Min.
- Gemergte PRs (30 T.)
- 6
Beschreibung
Describe the bug
After the desktop app auto-updated to 1.1.15, creating a new Local (branch-type) session in a project fails whenever another Local session in that same project has a live CLI process:
Session creation failed: Failed to create session: invalid argument: This project already has an active Local workspace.
This is a behavior change. Before 1.1.15 I routinely ran several Local sessions side by side in the same project, and had done so for ~3 months.
The blocking condition appears to be a running session, not the number of workspaces: at the moment of failure the project had 74 non-archived workspace_type='branch' workspaces, and exactly one session row with is_running = 1 — the session I was actively chatting in. So the app effectively enforces "one live Local session per project", and the currently-focused session is the thing that blocks creating the next one.
Affected version
Desktop app 1.1.15 (macOS). Bundled CLI: 1.0.83-5.
Steps to reproduce the behavior
- Open a project backed by a local checkout using Local / branch workspaces (not worktrees).
- Start a session in it and keep it active (live CLI process).
- Try to create another session in the same project.
- Creation fails with
invalid argument: This project already has an active Local workspace.
Expected behavior
Multiple Local sessions in the same project should be creatable concurrently, as they were in 1.1.13 / 1.1.14. If concurrent Local sessions must now be limited, the restriction should be documented and the error should say what to do about it (e.g. "stop session X first") rather than surfacing a raw invalid argument.
Additional context
Evidence that this is new in 1.1.15
| Check | Result |
|---|---|
Non-archived workspace_type='branch' workspaces in the affected project |
74, oldest 2026-06-16 → no historical single-workspace limit |
Occurrences of active Local workspace across 71 log files (back to Aug 22) |
0 before today; 7 failures today within ~11 minutes |
| First occurrence | 2026-09-06T20:35:22Z, on create_branch_workspace |
data.db.pre-update-backup-1.1.15-… timestamp |
2026-09-06 16:46 local — update to 1.1.15 preceded the first failure by ~6h |
sessions rows with is_running = 1 at failure time |
exactly 1 (the focused session) |
Possibly related new strings in the 1.1.15 binary, which suggest this comes from a new proactive branch-warmup mechanism:
This project already has an active Local workspace.Local workspace creation is still waiting for proactive warmup cleanup.Proactive branch warmup stopped because the shared checkout changed before the session started.internal error: entered unreachable code: branch workspace wait loop always returns
Why worktrees aren't a workaround here
The project in question is a personal Obsidian vault. The notes must live at one fixed path so the Obsidian app and the sessions see the same files, so Local/in-place is the only viable workspace type — a worktree would create a detached copy and break the vault. That makes "use worktrees instead" not an option, and "stop the session you're currently talking in before you can start another" a significant workflow regression for anyone using several topic-scoped sessions against one local checkout.
Environment
- macOS, Apple Silicon
- Desktop app 1.1.15, CLI 1.0.83-5
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginne damit, den Fehler über create_branch_workspace mit einer laufenden Local-Sitzung zu reproduzieren, und untersuche anschließend die 1.1.15-Logs sowie die gemeldeten Strings für das proaktive Aufwärmen des Branches. Als erledigt gilt die Aufgabe, wenn wieder mehrere Local-Sitzungen gleichzeitig erstellt werden können oder jede beabsichtigte Einschränkung mit einer umsetzbaren Fehlermeldung dokumentiert ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- macos, shell
- Bereich
- cli, desktop
- Issue-Typ
- Bug
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Aktiv
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 48/100