Desktop app 1.1.15: cannot create a second Local (branch) session while one is running — "This project already has an active Local workspace"
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- Shell
- Estrellas
- 11.2k
- Forks
- 1.9k
- Merge medio
- 14 h 16 min
- PR fusionados (30 d)
- 6
Descripción
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
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
Comienza reproduciendo el fallo mediante create_branch_workspace con una sesión Local en ejecución; después inspecciona los logs de 1.1.15 y las cadenas reportadas de calentamiento proactivo de la rama. Se considera completado cuando se puedan volver a crear varias sesiones Local de forma concurrente, o cuando cualquier restricción intencionada esté documentada con un mensaje de error accionable.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- macos, shell
- Área
- cli, desktop
- Tipo de issue
- Error
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Estado de actividad
- Activo
- Claridad
- Bastante claro
- Aptitud para principiantes
- 48/100