Codex App Pull Requests defaults to github.com and ignores authenticated GitHub Enterprise host

Start at the Pull Requests route and its empty-state host-selection logic, then trace the backend hostname handling and the pull-request-last-account persistence key. Done means an Enterprise-only authenticated host is discovered, inferred, or selectable instead of defaulting to github.com, with both authentication and current-user probes using that host.

What version of the Codex App are you using?

Codex App 26.715.31251 (build 5538).

What platform are you using?

macOS, Apple Silicon.

Summary

The top-level Pull Requests inbox defaults its authentication probe to github.com, even when GitHub CLI is authenticated only for a self-hosted GitHub Enterprise host. The UI consequently displays GitHub CLI setup required with gh: Requires authentication (HTTP 401), although Enterprise authentication and PR access work correctly.

The inbox supports Enterprise hostnames once an Enterprise PR/account has already been remembered, but the initial inbox provides no hostname/account selector and does not infer the host from configured gh accounts or Git remotes. This creates a bootstrap failure for Enterprise-only users.

Steps to reproduce

1. Configure and authenticate GitHub CLI for a self-hosted Enterprise host:

   gh auth login --hostname <enterprise-host> --web --git-protocol https
   

2. Do not have a valid github.com login.

3. Verify Enterprise access works:

   gh auth status --hostname <enterprise-host>
   gh api user --hostname <enterprise-host> --jq .login
   gh pr list --repo <enterprise-host>/<owner>/<repo> --limit 1
   

4. Restart Codex App.

5. Open the top-level Pull Requests navigation.

6. Click Check again.

Actual behavior

The Pull Requests page reports:

GitHub CLI setup required
gh: Requires authentication (HTTP 401)

Authenticating the Enterprise host again does not help. Removing a stale github.com account changes the aggregate CLI authentication state but does not make the inbox select the Enterprise host.

Expected behavior

When no account has been remembered, the Pull Requests inbox should do one of the following:

1. discover authenticated hosts from gh auth status and select the sole authenticated host;
2. infer the hostname from the active repository remote; or
3. present a hostname/account selector before probing the current user.

It should not silently default to github.com when only a GitHub Enterprise account is authenticated.

Verified diagnostics

The Enterprise credentials and API/PR access were verified outside the network-restricted tool sandbox:

✓ Logged in to <enterprise-host> account <redacted> (keyring)
- Active account: true
- Git operations protocol: https
- Token scopes: gist, read:org, repo, workflow

Both gh api user --hostname <enterprise-host> and gh pr list succeeded.

Packaged implementation evidence

Inspection of the installed app.asar shows the Pull Requests route defaults githubHostname to github.com when there is no selected PR or remembered account. The current-user query then executes the equivalent of:

gh api user --hostname github.com

The backend supports an explicit hostname and uses it for both probes:

gh auth status --active --hostname <hostname>
gh api user --hostname <hostname>

The persisted account key is pull-request-last-account, but there is no visible way to initialize it to an Enterprise host from the empty/error inbox.

This is related to openai/codex#33071, but narrower: GitHub Enterprise is already represented in the PR route and backend; the failure is the initial host-selection/bootstrap behavior.