Repository navigation
Sandbox pre-flight fails: proxy blocks api.github.com (HTTP 403) #6853
Description
What happened
The review agent for PR #5 on rhdh-parasol/plugin-empty failed at the pre-flight connectivity check in workflow run 33521605477. The error was: pre-flight connectivity check: GitHub API unreachable from sandbox (HTTP 403 - proxy allowlist issue): Get "https://api.github.com/rate_limit": Forbidden. The sandbox was running OpenShell v0.0.83 on an Azure eastus runner. All prior steps (checkout, workspace prep, token minting, GCP setup, agent env setup) succeeded — only the sandbox network connectivity failed.
What could go better
The review agent was completely unable to function because the sandbox proxy blocked outbound HTTPS to api.github.com. This is a hard prerequisite for any agent that needs to interact with GitHub (posting comments, fetching PR diffs, etc.). Without it, the entire review pipeline is a no-op.
Confidence: High that this is a real infrastructure issue, not a transient blip. The error message is specific (proxy allowlist issue, not a timeout or DNS failure), and the pre-flight check is designed to catch exactly this class of problem. Moderate confidence on root cause — it could be (a) a missing entry in the OpenShell gateway proxy allowlist, (b) a regression in OpenShell v0.0.83, or (c) a region-specific network policy issue on Azure eastus. Investigation is needed to determine which.
No existing open issues were found covering this in fullsend-ai/fullsend, fullsend-ai/agents, or rhdh-parasol/plugin-empty.
Proposed change
Investigate and fix the OpenShell gateway proxy allowlist to ensure api.github.com (and likely *.github.com) is permitted for HTTPS CONNECT from within sandboxes. The error message in the harness already points to the right area: "Check the OpenShell gateway network policy and proxy allowlist configuration." Specific steps:
- Check the OpenShell gateway proxy allowlist configuration for the sandbox environment to verify whether
api.github.comis included. - If missing, add it. If present, investigate whether OpenShell v0.0.83 introduced a regression in proxy handling or whether the Azure eastus region has a different network policy.
- Verify the fix by re-running a review agent on a test PR.
Validation criteria
The next 3 review agent runs on rhdh-parasol/plugin-empty (or any repo using the same sandbox infrastructure) should pass the pre-flight connectivity check without HTTP 403 errors. The pre-flight step should report successful GitHub API connectivity.
Generated by retro agent from rhdh-parasol/plugin-empty#5
Activity
ralphbean commentedon Sep 24, 2026
/fs-triage lots of things have changed between when this was originally filed and now across both the https://github.com/fullsend-ai/fullsend and https://github.com/fullsend-ai/agents repos. Is this still relevant? This is a stale-issue review, not an implementation request: even if the issue is still a valid bug and has sufficient information, do not recommend or trigger ready-to-code yet. Leave it for human prioritization after confirming whether it remains relevant. Do not close a still-relevant bug merely to avoid coding it.
fullsend-ai-triage commentedon Sep 24, 2026
🤖 Finished Triage · ✅ Success · Started 7:19 PM UTC · Completed 7:27 PM UTC
Commit:
3871d1b· View workflow run →Runtime: claude · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $0.75
fullsend-ai-triage commentedon Sep 24, 2026
Re-checked relevance per the request above.
The local GitHub-egress allowlist profiles that would need a GitHub API host entry (both in this repo and in fullsend-ai/agents) already contained that entry before this incident happened (added 2026-08-13, incident on 2026-09-01) -- so this was never a missing-config problem on the fullsend side. A sibling report filed the same day from a different repo's review-agent run hit the identical pre-flight 403 and explicitly characterized it as a transient proxy blip (no other runs in that repo's last 30 had the failure). No further occurrences of this failure mode show up in the tracker in the roughly three weeks since, despite continued review-agent activity, and the fleet's OpenShell pin has advanced from v0.0.83 to v0.0.116 over that period.
Taken together, this looks like a transient (possibly version- or region-specific) fault in the external OpenShell gateway rather than an ongoing, repo-fixable defect -- but since it can't be independently confirmed as permanently resolved from here, the issue is being left open rather than closed. Per the request, this has been categorized as an infrastructure/ops item rather than an in-repo bug, so it will not auto-trigger the code agent; a maintainer can decide whether to close it or keep it open for further monitoring. The related resilience mitigation (retry-with-backoff on the pre-flight check) remains separately tracked and open as #6855.
Labels: This is a sandbox/OpenShell-gateway connectivity report that, per the requester's instruction, should sit with a human rather than auto-triggering implementation work.
Next steps:
/fs-code— agent creates a PR to implement this issue/fs-code <your instruction>— agent implements with your specific guidance