Repository navigation
Workspace branch name (pr-N) doesn't match the actual PR branch (issue-N-hash), causing pushes and session-backup to target the wrong PR #400
Description
Problem
When a workspace is created to work on a PR, it checks out a branch named `pr-{N}` (e.g. `pr-387`).
But the PR on GitHub was opened from a branch named `issue-{issue}-{hash}` (e.g. `issue-383-173b143467d9`).
These are two different branches — so every git push and every session-backup comment lands on the wrong PR.
How it manifests
Observed in PR #387 / issue #383:
| What happened | Expected |
|---|---|
| Local branch: `pr-387` | Should be: `issue-383-173b143467d9` |
| `git push origin pr-387` → updates PR #399 (auto-created for `pr-387`) | Should update PR #387 |
| Session-backup comments posted to PR #399 | Should be posted to PR #387 |
| `gh pr merge 387` works, but agent never pushes to the right branch by default | Agent should push to the PR's actual head branch |
| Merging `main` into workspace required manual `git push origin pr-387:issue-383-173b143467d9` | Should happen transparently |
Root cause
In `packages/docker-git-session-sync/src/backup.ts`, `getPrNumberFromWorkspaceBranch` only recognises branches matching `pr-refs-pull-{N}-head`:
```typescript
const getPrNumberFromWorkspaceBranch = (branch: string): number | null => {
const match = branch.match(/^pr-refs-pull-([0-9]+)-head$/u) // ← never matches "pr-387"
...
}
```
And `findPrContext` falls back to `gh pr list --head pr-387`, which finds PR #399 (the auto-created PR for the `pr-387` branch) — not the intended PR #387.
The workspace provisioning creates branch `pr-387` instead of checking out the existing PR branch `issue-383-173b143467d9`.
Suggested fix
When provisioning a workspace for PR #N:
- Fetch the PR's actual head branch via `gh pr view N --json headRefName` and check it out instead of creating `pr-N`.
- Or, store the target PR number in the workspace config (e.g. `.docker-git/workspace.json`) so the agent and session-backup can always resolve the correct PR regardless of local branch name.
- Or, extend `getPrNumberFromWorkspaceBranch` to also match `pr-{N}` → treat it as PR number `N` (quick workaround, but doesn't fix the push-to-wrong-branch issue).
Option 1 is the cleanest: the local branch name matches what GitHub expects, and all tooling works without special-casing.
Frequency
This happens on every workspace that is created for an existing PR — the pattern is consistent across all recent PRs in this repo (all use `issue-{N}-{hash}` branch names, all workspaces land on `pr-{N}`).
Activity