Agent reports stale PR review after sandboxed GitHub access fails despite available scoped escalation

[goneflyin]

Summary

During a requested re-review of a GitHub PR, Codex ran gh pr view inside a workspace-write sandbox with restricted network access. The command failed to connect to api.github.com. The agent treated that as a GitHub connectivity problem, reviewed its stale local branch, and reported findings that the submitter had already fixed in a newer PR commit. It then told the user it could not verify the remote head.

A narrowly scoped retry outside the sandbox succeeded immediately with the same gh installation and authentication. This is an agent escalation/diagnosis failure, not evidence that GitHub or the user's network was down.

Related: #47658 (closed after its reporter enabled sandbox networking); #31017 covers a different gh credential symptom.

Environment

• Codex CLI 0.158.0, ChatGPT desktop local command execution on macOS 26.5.2
• GitHub CLI 2.96.0
• workspace-write sandbox, restricted network, approvals_reviewer = "auto_review"
• gh authenticated as the expected user through GITHUB_TOKEN
• Public PR: fix(matching): attribute coverage to generic and overloaded methods 7Factor/crap4dotnet#4

Reproduction and evidence

1. Ask Codex to re-review that PR after the submitter pushes a new commit.
2. Sandboxed gh pr view 4 --json ... exits 1: error connecting to api.github.com.
3. Sandboxed git ls-remote origin 'refs/pull/4/head' exits 128: ssh: Could not resolve hostname github.com.
4. Codex continues against local commit 52656cd, reports two defects, and says GitHub is unavailable. The actual PR head is 6952d40, which fixes both defects.
5. The same session retries gh pr view 4 --json number,title,headRefOid,... with sandbox_permissions: "require_escalated", a read-only gh pr view prefix rule, and a narrow justification. It exits 0 and reports headRefOid: 6952d40.... git fetch origin pull/4/head:refs/remotes/origin/pr/4 likewise succeeds with scoped escalation.

No authentication or host-network configuration changed between steps 2 and 5.

Expected behavior

For a task that requires current remote SCM state, the agent should recognize a restricted-sandbox network/DNS failure, distinguish it from host connectivity or authentication, and retry an authorized read-only SCM command through scoped escalation before reviewing or claiming the PR cannot be verified. If escalation is unavailable or denied, it should stop short of a current-head review and identify the precise boundary.

The product could also make ordinary read-only SCM inspection easier to authorize through a narrow default capability or clearer configuration guidance, while keeping write operations and broad network access separate.

Actual behavior and impact

The agent reported stale, already-fixed defects as current review findings. The user had to diagnose Codex's execution context and prompt it to use the CLI correctly. This defeats the point of PR re-review and makes sandboxing feel like a misleading failure mode rather than a useful boundary.

[Keesan12]

The failure boundary here seems important: once current remote state is required, stale local state should not be allowed to satisfy the task.

A harness can make that explicit by treating network/approval posture as part of the run contract. If the required remote read is blocked, either use the permitted scoped escalation or fail closed with "current head unverified." Continuing with stale state creates a plausible-looking but invalid review.

I maintain MartinLoop, and we use execution profiles plus network/approval gates for this kind of boundary: https://github.com/Keesan12/martin-loop

It does not replace Codex's sandbox policy. It makes the missing prerequisite visible before the run can claim a verified result.

[84dnnvbdvp-debug]

Current source suggests there are two separate failure layers here.

UnifiedExecRuntime::escalate_on_failure() is true, but the orchestrator's automatic retry path only runs when the first attempt returns a structured CodexErrorDetails::Sandbox(SandboxErr::Denied { ... }). Other failures return immediately from the orchestrator without the escalation retry.

That matters for this repro because gh pr view exits 1 with error connecting to api.github.com and git ls-remote exits 128 with DNS text. If those network-denied processes surface as ordinary command exit/output rather than SandboxErr::Denied, the runtime never reaches its built-in approval/retry path even though a scoped escalated retry would succeed. The remaining burden falls entirely on model diagnosis.

A useful regression would exercise the real restricted-network sandbox with a read-only command that fails exactly this way and assert one of two intentional contracts:

1. the runtime classifies policy-caused network failure as a structured sandbox/network denial so the existing escalation path can engage; or
2. the tool result carries an explicit sandbox/network-blocked signal strong enough that the agent must not reinterpret it as host/GitHub outage or continue a current-head task from stale local state.

That would separate 'model failed to infer escalation from generic stderr' from 'runtime failed to expose the denial through the path it already knows how to escalate.'