Problem
Workspaces that have valid upstream pull requests opened from a fork do not show PR status in the top-right workspace header / inspector surfaces.
Observed examples in the local Helmor workspace list:
The PRs exist and are open, but the corresponding workspace rows remain with pr_sync_state = none and no pr_url, so the UI behaves as if no PR is linked.
Why it happens
The GitHub PR lookup uses pullRequests(headRefName: ...), then drops every result where isCrossRepository is true:
src-tauri/src/forge/github/pull_request.rs -> pick_in_repo_prsrc-tauri/src/forge/github/actions.rs -> pick_in_repo_action_pr
That was introduced in aa034942e28b7aa670adc8bd6633fcfef0af9c54 / #434 to avoid mis-associating a workspace on a shared branch like main with an unrelated fork PR using the same branch name.
That fix prevents false positives, but it also filters out legitimate fork PRs created by the bound forge account.
Suggested fix
Do not reject all cross-repository PRs. Instead, accept a cross-repository PR when its fork owner matches the repository's bound forge account.
Suggested matching rule:
The GraphQL query already has access to isCrossRepository; it likely needs to also select headRepositoryOwner { login } for both lookup and action-status queries.
Validation
A good regression test would cover:
- same-repository PR still matches
- cross-repository PR from unrelated owner is ignored
- cross-repository PR from the bound
forge_login is matched and syncs pr_sync_state / pr_url
- action status uses the same matching behavior as PR lookup
Problem
Workspaces that have valid upstream pull requests opened from a fork do not show PR status in the top-right workspace header / inspector surfaces.
Observed examples in the local Helmor workspace list:
aidxun/custom-repository-display-names-> fix: show repository paths in repository picker #473aidxun/agent-proxy-settings-> feat: add agent proxy settings #409aidxun/remove-sidebar-animation-> Remove inspector toggle animations #422aidxun/fix-workspace-ashare-repo-selection-> fix: resolve session workspace for agent streams #420aidxun/add-dnd-to-workspaces-> Add drag-and-drop workspace ordering in sidebar #444The PRs exist and are open, but the corresponding workspace rows remain with
pr_sync_state = noneand nopr_url, so the UI behaves as if no PR is linked.Why it happens
The GitHub PR lookup uses
pullRequests(headRefName: ...), then drops every result whereisCrossRepositoryis true:src-tauri/src/forge/github/pull_request.rs->pick_in_repo_prsrc-tauri/src/forge/github/actions.rs->pick_in_repo_action_prThat was introduced in
aa034942e28b7aa670adc8bd6633fcfef0af9c54/ #434 to avoid mis-associating a workspace on a shared branch likemainwith an unrelated fork PR using the same branch name.That fix prevents false positives, but it also filters out legitimate fork PRs created by the bound forge account.
Suggested fix
Do not reject all cross-repository PRs. Instead, accept a cross-repository PR when its fork owner matches the repository's bound forge account.
Suggested matching rule:
headRepositoryOwner.login == repos.forge_loginThe GraphQL query already has access to
isCrossRepository; it likely needs to also selectheadRepositoryOwner { login }for both lookup and action-status queries.Validation
A good regression test would cover:
forge_loginis matched and syncspr_sync_state/pr_url