**My work entry becomes permanently unusable and un-removable when a PR's bas...

Look for the code that prepares worktrees and fetches refs, likely in a module handling 'My work' sessions. The fetch command with multiple refspecs is the culprit. Start by searching for 'git fetch' and 'refs/pull' in the codebase. Understand how the app constructs the fetch command when opening a PR. The fix involves modifying the fetch logic to handle missing base branches gracefully, perhaps by fetching refs separately or using a glob pattern. Test by simulating the scenario in a development environment.

My work entry becomes permanently unusable and un-removable when a PR's base branch is deleted

Summary

In the My work view, a merged PR whose head/base branches no longer exist stays listed forever with Session: Unavailable. It can never be opened (worktree preparation fails), and there is no way to remove the entry.

Environment

• GitHub Copilot app 1.1.23 (github.exe, Windows)

• git 2.53.0.windows.4

• Private GitHub.com repo; PR was squash-merged and both source branches were deleted afterwards

Steps to reproduce

1. Have a PR whose base branch exists (works normally at this point).

2. Merge it (squash), then delete the head and base branches.

3. Open My work — the PR is still listed (seen in the All and Done views).

4. Try to open it.

Actual

Worktree preparation runs:

Bash

git fetch --no-write-fetch-head origin \
  +refs/heads/<base-branch>:refs/remotes/origin/<base-branch> \
  +refs/pull/<N>/head:refs/remotes/origin/pr/<N>

and fails with:

Plain text

fatal: couldn't find remote ref refs/heads/<base-branch>

exit code 128, so the session/worktree can't be created. The row remains in the list with Session: Unavailable, permanently.

Root cause / evidence

• refs/pull/<N>/head still resolves after a merge, but a single git fetch with multiple refspecs is all-or-nothing: one missing ref aborts the whole fetch and nothing is written — not even the ref that does exist. Reproduced in a clean temporary clone: exit 128, and git for-each-ref shows zero refs written.

• Fetching only +refs/pull/<N>/head:refs/remotes/origin/pr/<N> succeeds (exit 0), so the PR ref alone would be enough.

• git ls-remote origin "refs/pull/<N>/*" confirms the ref is still available.

Suggested fix

• Don't put the base-branch and PR-head refspecs in a single fetch; or

• treat a missing base ref as non-fatal (fetch the PR ref, continue, and degrade the diff base); or

• use a glob refspec for the base branch — verified that +refs/heads/<pattern>/*:refs/remotes/origin/<pattern>/* exits 0 silently when nothing matches, while an explicit missing ref name is a hard error.

• Note: git fetch --no-error-on-missing-ref does not exist in git 2.53.0.windows.4, so that isn't available.

No workaround currently exists in the UI

Checked in 1.1.23: right-clicking the row → no context menu; Actions → no menu appears for this item; right-clicking the view tab → only Duplicate / Reorder views (no rename/edit-query/delete). The All view's saved query is empty (catch-all), so the entry is always shown there.

Related

#713 (dismiss/snooze individual items in My work) would give an escape hatch, but the underlying fetch failure is a bug on its own.