Multi-repo collection workspace never associates a worktree when member repos have different default branches (main vs master)

Describe the bug

In a collection project (one folder containing several independent git repositories), agent-created sessions are permanently unusable if the member repos do not all share the same default branch name.

The worktrees are created successfully on disk, but the workspace→worktree association is never persisted. Every subsequent operation that needs it fails with:

workspace <workspace-id> has no associated worktree

This breaks create_session (kickoff never delivered), send_session_message, and navigate_to for that session. The session appears healthy in the sidebar and get_session returns a valid path, branch and session_type: worktree — but nothing can ever be dispatched to it.

Root cause: the app appears to assume the default branch is main when enumerating collection members. My collection contains two repos:

Member	Default branch	Has main?
repo-a	main	yes
repo-b	master	no

git rev-parse main is run against every member and throws on repo-b, which has no main ref at all. The logs show this repeating continuously:

WARN github_app::workspace::changes: collection member changes failed
  workspace_id=<ws> checkout=repo-b
  error=git ["rev-parse", "main"] failed: not found

Meanwhile the worktree creation itself clearly succeeded for both members:

INFO github_app::git::worktree: create worktree completed
  branch="<generated-branch>" worktree_path=...\<generated-branch>\repo-b  existing_branch=false
INFO github_app::git::worktree: create worktree completed
  branch="<generated-branch>" worktree_path=...\<generated-branch>\repo-a  existing_branch=false

…and yet dispatch to that same workspace still fails:

WARN github_app::tools::send_session_message: failed to ensure target workspace session
  workspace_id=<ws> error=workspace <ws> has no associated worktree

The failure is permanent and deterministic for the affected workspace — it survives app restarts, and survives removing all stale worktrees and pruning. I have reproduced it across 5+ separately created sessions over two app restarts.

Notably, the built-in "create issue" tool in the app also fails with this same error when invoked from a session in an affected collection, so the broken association blocks unrelated features too — I had to file this issue via gh instead.

Affected version

GitHub Copilot CLI 1.0.80
GitHub Copilot app 1.1.14 (commit 0d498e8, platform=windows, arch=x86_64)
embedded git 2.53.0-4

Steps to reproduce the behavior

1. Create a folder containing two git repositories, where the default branch names differ:
   • repo-a — default branch main (no master ref)
   • repo-b — default branch master (no main ref)
2. Add that folder as a project, so it is treated as a multi-repo collection.
3. From an agent session in that project, call create_session with a kickoff prompt.
4. create_session returns:

   Created session '<name>' (id: <ws>), but failed to start its Copilot session:
   workspace <ws> has no associated worktree
   

5. Confirm the worktrees do exist on disk and are checked out correctly at the expected commit for both members.
6. Confirm get_session <ws> returns a healthy record with a valid path and session_type: worktree.
7. Retry with send_session_message (any delivery_mode) or navigate_to — both fail with the same has no associated worktree error, indefinitely.

Expected behavior

Collection member enumeration should resolve each repository's own default branch rather than assuming main — e.g. via refs/remotes/origin/HEAD, or git symbolic-ref --short HEAD, or per-member configuration.

A member repo that uses master (or any other default branch name) should not prevent the workspace→worktree association from being written, and should not render the whole session permanently undispatchable.

Additionally, failure to enumerate one member's changes should be non-fatal to the association of the workspace as a whole — the worktrees were created successfully, so the association is recoverable.

Additional context

Likely second, separate bug — a race in create_session:

create_session reports the has no associated worktree failure ~22 seconds before initialisation actually finishes:

11:55:52.282  INFO github_app::tools::create_session: create_session workspace created      workspace_id=<ws> has_kickoff=true is_cloud=false
11:56:14.887  INFO github_app::tools::create_session: create_session workspace initialized  workspace_id=<ws>

The tool returned its error at 11:55:52, but workspace initialized was not logged until 11:56:14. So create_session evaluates the association before initialize_collection_worktree_set has completed. That race is what initially made this look intermittent/environmental — worth fixing independently of the default-branch issue, since even after a correct fix to branch resolution the kickoff could still be dropped.

Impact: this blocks agent-orchestrated fan-out entirely on mixed-default-branch collections. The only workaround is to open each session manually in the UI and paste the prompt by hand, which defeats the purpose of programmatic session creation.

Environment:

• OS: Windows 11 (10.0.26200), x86_64
• Both member repos are Azure DevOps remotes (not GitHub-hosted), if relevant to default-branch detection
• Repository and organisation names have been redacted; happy to supply fuller logs privately if useful

Start in the workspace changes and worktree paths shown by the logs: github_app::workspace::changes, github_app::git::worktree, and the create_session and send_session_message tools. Trace collection member branch resolution and initialize_collection_worktree_set ordering; done means mixed main/master collections persist their workspace-to-worktree association and create_session, message delivery, and navigation work without the missing-association error.