Deleted fork remote strands project sessions with no recovery path

[IEvangelist]

Summary

A Copilot app project can become unrecoverable when its local base clone still has origin pointing at a fork that has since been deleted, even though the app/project metadata points at the canonical upstream repository.

In my case, the aspire project is configured as microsoft/aspire, and current workflow is to use the official upstream/main / canonical repo directly. A previous session had created or used an IEvangelist/aspire fork. I later deleted that fork because I did not want it anymore.

After the fork was deleted, creating a new session/worktree for the microsoft/aspire project failed permanently because the app still tried to fetch from the deleted fork URL.

Observed failure

When creating a new session/worktree, the app ran a fetch equivalent to:

git ["-C", "C:\\Users\\dapine\\.copilot\\repos\\aspire", "-c", "credential.helper=", "fetch", "--progress", "https://x-access-token:[REDACTED]@github.com/IEvangelist/aspire.git", "+refs/heads/main:refs/remotes/origin/main"] failed: remote: Repository not found.
fatal: repository 'https://github.com/IEvangelist/aspire.git/' not found

The project record itself is for:

microsoft/aspire

But the local clone still had stale Git remote config:

origin   https://github.com/IEvangelist/aspire.git
upstream https://github.com/microsoft/aspire.git

So worktree creation kept trusting the stale local origin URL instead of recovering from the app's configured project repo.

Why this is a problem

This state is not recoverable from inside the app. Once the fork is deleted, every new session/worktree creation for that project can fail because origin/main points at a repository that no longer exists. The user is effectively stranded unless they know to manually edit the Git remote config outside the app.

The app should be able to recover because it already knows the canonical project repo is microsoft/aspire.

Expected behavior

The app should detect this stale/deleted fork remote state and provide a recovery path, for example:

• If origin returns repository-not-found but the project metadata has a canonical GitHub repo, offer to reset origin to that repo.
• Prefer the configured project repo over stale local remote config when creating new worktrees.
• If both origin and upstream exist and upstream matches the configured project repo, use or promote that remote instead of failing permanently.
• Show an actionable recovery prompt in the UI rather than leaving the session creation stuck.

Manual workaround

This fixes the local state manually:

git -C "C:\Users\dapine\.copilot\repos\aspire" remote set-url origin https://github.com/microsoft/aspire.git
git -C "C:\Users\dapine\.copilot\repos\aspire" fetch origin main

But this should not require manual Git surgery, especially when the app already has the correct project repository configured.

Environment

• App version: 1.0.55-0
• OS: Windows_NT
• Project: microsoft/aspire

[IEvangelist]

Additional finding after a deeper local audit: fixing only remote.origin.url is not sufficient.

In this user's state there were multiple durable sources that could preserve or reintroduce the deleted fork URL:

1. C:\Users\dapine\.copilot\settings.json had a sessionSync entry:

{
  "origin": "IEvangelist/aspire",
  "level": "user"
}

2. C:\Users\dapine\.copilot\repos\aspire\.git\config had branch-level config values that stored the full deleted fork URL directly, not just a remote name:

[branch "dapine/fix-resolver-silent-loader-failures-16729"]
    remote = https://github.com/IEvangelist/aspire.git
    pushRemote = https://github.com/IEvangelist/aspire.git

[branch "dapine/issue-15120-yarp-polyglot"]
    remote = https://github.com/IEvangelist/aspire.git
    pushRemote = https://github.com/IEvangelist/aspire.git

After changing origin to https://github.com/microsoft/aspire.git, updating the sessionSync origin to microsoft/aspire, and replacing those branch-level remote entries with origin while removing the stale pushRemote values, git fetch origin main succeeds again.

Suggested recovery should therefore reconcile more than remote.origin.url: it should also audit app-level sync settings/cache and branch-level Git config for full repository URLs that point at a missing/deleted fork, especially when project metadata already identifies the canonical repo.