Desktop app 1.1.15: cannot create a second Local (branch) session while one is running — "This project already has an active Local workspace"

[DannyBe99]

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

1. Open a project backed by a local checkout using Local / branch workspaces (not worktrees).
2. Start a session in it and keep it active (live CLI process).
3. Try to create another session in the same project.
4. 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

[brandonmartinez]

Confirming this on 1.1.15 (macOS, bundled CLI 1.0.83-5), and adding the success-path variant of the same enforcement — I think they're the same root cause seen from two sides.

I hit your exact error twice:

2026-09-05T13:59:08Z ERROR github_app::handlers::workspace: failed to create branch workspace
                     error=invalid argument: This project already has an active Local workspace.
2026-09-05T14:00:08Z ERROR (same)

But when no Local session is running, creation doesn't fail — it silently reuses the existing Local workspace instead:

Local session running?	Result
Yes	creation fails — This project already has an active Local workspace (this issue)
No	creation succeeds by reusing the one existing Local workspace

Evidence for the reuse path

The client asks for it explicitly. Comparing two ensure_session_warmup payloads sent ~35s apart in the same project:

// worktree session -> new workspace created
{"workspace_type": "worktree", "base_branch": "main"}

// Local/branch session -> reuse requested by the client
{"workspace_type": "branch",
 "existing_workspace_id": "<the one pre-existing Local workspace>"}

Three consecutive New Session clicks (distinct composer ids) each carried the same existing_workspace_id, and all three sessions were aliased onto one workspace created 8 days earlier:

3f283d07  "Remote vault search"                       2026-08-30   <- original
a2b469c4  (untitled)                                  2026-09-06
f6308235  "Testin to see if this spins up a new ses"  2026-09-07
45e3e721  "this is another test to see if it spins"   2026-09-07

Deterministic, 3/3.

Consequence: the shared workspace keeps a stale name

workspaces.name is written once at creation and never revised, so the shared checkout is permanently labeled after whichever task created it first. The header and sidebar both render workspaces.name, so every new session appears as "Remote vault search" — a task from 8 days ago.

sessions.title is generated correctly per conversation (title_source='auto', values above), it's just not what's displayed. Conversation history is not contaminated — separate events.jsonl per session (21 events vs 219) — but it reads like sessions are being merged, which is how I found this.

This is a behavior change, not a pre-existing limit

Same as your 74: I have 11 non-archived workspace_type='branch' workspaces on one project's main, oldest 2026-08-07. The old behavior clearly allowed many Local workspaces per project.

Across the whole install, only branch workspaces accumulate multiple unrelated sessions:

workspace_type  workspaces  sessions  avg_per_ws  max_in_one
branch          15          16        1.07        2
worktree         2           2        1.0         1

Same worktree constraint

+1 on worktrees not being a workaround. My case is also a personal Obsidian vault — the notes must stay at one fixed path so the Obsidian app and the sessions see the same files. A worktree makes a detached copy and breaks the vault, so Local/in-place is the only viable workspace type.

Two suggestions if the one-Local-workspace rule is intentional:

1. Name the shared workspace neutrally (e.g. after the project/branch, <project> (main)) or let it follow the active session, instead of pinning it to the first task's title.
2. Make reuse visible in the UI, so it's clear a new session joined an existing workspace rather than getting its own.

Separately, on the same 1.1.15 build I'm seeing every session.create block ~30s (was 0.6–0.9s); filed as github/app#3575 since it reproduces with no repo attached at all.

[dhrubajy]

github/app#3530

[Leo-ATP]

For anyone on Windows, this is how I rolled back to 1.1.14:

1. In the GitHub Copilot app, ask Copilot to downgrade the app to 1.1.14 and prevent it from automatically reinstalling 1.1.15. Copilot can handle the download, downgrade, staged-update cleanup, and update blocking for you.

2. Once it finishes, fully quit the app.

3. Open:

   C:\Users\{username}\.copilot\
   

4. You should see files similar to:

   data.db
   data.db.pre-update-backup-1.1.15-{timestamp}
   

5. Rename the current data.db to data.db.1.1.15.bak, then rename the latest appropriate data.db.pre-update-backup-1.1.15-{timestamp} to data.db.

6. Start GitHub Copilot again.

The only manual part is restoring the database file. Back up the entire .copilot folder first.
Work created after upgrading to 1.1.15 will NOT be present in the restored database.

[fedejeanne]

@Leo-ATP thank you for the workaround! I was able to do it successfully. In fact, I was trying it right before you edited the comment and added the part about staged updates.

What I did differently is:

• Before closing the App in v1.1.15 I disabled Automatically check for updates under Settings > General

By doing that, I didn't need to remove any write permissions in any folder, the App simply didn't wanted them anymore.

Then I installed v1.1.14 and did the whole renaming, as you described.

One important detail (should be obvious, but still) is that one should choose not to remove the local data when the install wizard asks (sorry, I don't recall the exact wording in the wizard).

[Leo-ATP]

@fedejeanne Thank you for the clarification! The earlier versions of my comment were generated by Copilot. I wasn't satisfied with how complicated they were, so I asked it to revise the comment.

The key part I actually wanted to contribute was restoring the compatible database by renaming the pre-update backup to data.db; Copilot handled the rest of the downgrade process for me. Your note about disabling Automatically check for updates first—and keeping the local data during installation—is much clearer and very helpful. Thanks!

[IronFox]

So, right, that happened. I tried instructing copilot but it couldn't find a legitimate download link. So I had to do it manually after all. For the record: setting to disable automatic updates in 1.1.15 does NOT carry over to 1.1.14 unless it was already switched off there. I disabled it, uninstalled, installed 1.1.14, but it redownloaded 1.1.15 so quickly by the time I had hit the checkbox, it had already completed the download. I couldn't stop it from upgrading. The installation conveniently has no cancel button. But now that the switch was flipped, doing it all over AGAIN now worked. Someone has to fix this. The more people complete this workaround, the less ability Github has to affect local installations.