Attached GitHub PRs show 404 despite successful connector and CI-check access #54034

Summary

Attached GitHub pull requests show 404 in the desktop app's native PR review view even though the same pull requests are accessible through the GitHub connector and Codex's CI-check tool. The user reports the failure across multiple pull requests.

Environment

• Desktop app: ChatGPT 26.1007.71326, build 20398 (Codex workspace).
• macOS 27.0.1, build 26A434.
• Observed on October 14, 2026.
• Two GitHub accounts are configured. Diagnostic reads explicitly selected the account authorized for the affected repository.

Steps to reproduce

1. Open a local repository task in the desktop app's Codex workspace.
2. Attach a valid GitHub pull request with attach_artifact(artifact_type="pull_request", url=<canonical PR URL>).
3. Open the attached PR in the native review view.
4. Observe 404 instead of the PR metadata and diff.
5. Remove and reattach the PR, then open it again: the failure persists.

Actual behavior and diagnostics

• The user sees 404 inside the desktop app; removing and reattaching repeatedly does not resolve it.
• attach_artifact succeeds, and list_artifacts returns a pull_request entry with the correct URL and GitHub identity.
• The attachment payload contains root: null and headBranch: null. This is an observation, not an established cause.
• The GitHub connector's get_pr_info successfully reads the same open, non-draft PR. Codex's pull_requests_checks, explicitly selecting the authorized account, also successfully retrieves its CI checks.
• open_in_codex accepts a PR review link with a file path and positive line number and returns status: "queued", but the user still reports 404 in the review UI.

Expected behavior

The native PR review view resolves an attached, accessible GitHub pull request and displays its metadata and diff. If that view requires a different authorization context, it should explain the required connection rather than present an unexplained 404.

Privacy and limits

Private repository names, PR URLs, source code, account identifiers, session transcripts, and raw logs are omitted. The UI error is user-reported; agent diagnostics verify successful attachment registration and successful API reads. The underlying failing HTTP endpoint and root cause have not been identified.