Collection worktree sessions only materialize a random 0-4 of 45 member repos, rest silently missing

[seanxiangct]

Short summary

New worktree sessions for a folder-based "collection" project only get a git worktree for a small, seemingly arbitrary subset of the collection's member repos (often exactly 2), while the rest are silently never checked out - even though the app's own DB records intend all of them to be checked out.

Affected version or release

1.1.16 (macOS)

Installation context

Local desktop app, "collection" project type, main_repo_path = a plain folder (~/Development) containing 45 separate git repos, registered via folder-project detection (not a single git repo).

What happened?

For a "collection" project spanning 45 member repos (tracked correctly in the collection_members table), every new worktree session should materialize a working checkout of the member repos it needs. In practice:

• workspace_checkout_bindings records all 45 member repos with checkout_kind='worktree' for every session - i.e. the data model's intent is a full multi-repo checkout.
• But on disk (and confirmed via git worktree list on each member repo, and via app logs showing github_app::git::worktree: create worktree completed ... deferred_checkout=false), only a small subset - usually exactly 2 repos, occasionally 3-4, and sometimes 0 - actually get a real git worktree add at session creation. The remaining ~40+ repos are never materialized; there is no error and no later "recreate" attempt.
• This is consistent across 40+ real sessions spanning 2+ months: whichever 0-4 repos get eagerly checked out do not correlate with the session's actual task/prompt topic. Cross-checking session_files/turns for 3 sample sessions confirmed the assistant never even touched a file inside the checked-out repos in 2 of them - so it isn't "the repos the session actually used."
• Once a session is running, there appears to be no working path to pull in an additional member repo on demand: neither a plain filesystem cd/ls into the missing repo's path, nor the CLI's own file-read tool, materializes it - both simply report the path doesn't exist.
• Occasionally the app logs failed to resume session ... error=this session's worktree is missing; recreate the worktree, then retry for these collection sessions, suggesting the app itself sometimes loses track of even the 2 eagerly-created worktrees.

Net effect: opening a session against a multi-repo "collection" folder essentially never gives you the specific repo you actually need pre-checked-out, and there's no discoverable/working mechanism inside the session to add it.

Steps to reproduce

1. Register a plain folder containing many independent git repos as a Copilot "collection" project (not linked to a single GitHub repo).
2. Create several new worktree sessions against that collection project over time, with different prompts/tasks that reference different member repos.
3. Inspect the resulting worktree folder on disk (//), or run git worktree list inside each member repo.
4. Observe that only a small, session-topic-independent subset of member repos, out of 45 members) is actually present, regardless of which repo the session's task actually needed.

Expected behavior

Either:

• All (or at least the specific repo(s) referenced by the session's task) member repos should be materialized as real worktrees, or
• If eager checkout is intentionally deferred/lazy as a performance optimization, there should be a reliable, discoverable mechanism (reachable from the CLI's own file tools, not just some internal/UI-only hook) to materialize a specific member repo on first access from within the session, so the agent isn't blocked working on a repo that "exists" in the collection but wasn't part of the initial eager set.