[codex] Fix loopback backend fetch failures#754
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
@OpenHands /iterate |
|
I'm on it! neubig can track my progress at all-hands.dev |
Co-authored-by: openhands <openhands@all-hands.dev>
all-hands-bot
left a comment
There was a problem hiding this comment.
🟢 Good taste - Elegant, centralized solution to a real browser connectivity issue.
Key strengths:
- Solves the specific problem: remote browsers can't reach loopback backend URLs
- Centralized in
resolveBrowserReachableAgentServerBaseUrl()and applied consistently across all call sites - Comprehensive test coverage for both loopback resolution and non-loopback preservation
- Backward compatible - only affects the problematic scenario
[RISK ASSESSMENT]
- [Overall PR]
⚠️ Risk Assessment: 🟢 LOW
Focused bug fix with no breaking changes. Logic is sound and well-tested.
VERDICT:
✅ Worth merging - Clean implementation with proper test coverage.
Was this automated review useful? React with 👍 or 👎 to this review to help us measure review quality.
Workflow run: https://github.com/OpenHands/agent-canvas/actions/runs/26380965296
|
Since the last summary, there were no additional code changes or tool actions. Final status:
The PR is merge-ready. |
|
@OpenHands I think we may need to think this through more carefully. Would this break the situation where someone is looking at separately-hosted frontend, but the agent-server backend is running on the local machine? |
|
I'm on it! neubig can track my progress at all-hands.dev |
Co-authored-by: openhands <openhands@all-hands.dev>
|
Thanks for calling this out — yes, the previous version of the PR was too broad and could break that setup. It rewrote any loopback backend whenever the browser hostname was non-loopback, so a separately hosted frontend that intentionally talks to I pushed
Validation passed:
This comment was created by an AI agent (OpenHands) on behalf of the user. |
|
Since the last summary, there were no additional tool actions or code changes. Final status:
|
📸 Snapshot Test ReportWarning Snapshot comparison step crashed (timeout, OOM, or runner error) — diff results below may be incomplete or absent. ❌ 1 snapshot differ from the main branch baseline. Add the
✅ Unchanged snapshots (72)
Generated by the Snapshot Tests workflow. This comment was created by an AI agent (OpenHands) on behalf of the repo maintainers. |



Summary
Fixes browser-level
Failed to fetchfailures when agent-canvas is opened from a remote hostname but the stored local backend still points at loopback (localhost/127.0.0.1). The existing browser-origin fallback only applied to the default agent-server config path, so stored backend entries could still make typed SDK clients and local proxy callers fetch an unreachable loopback URL from the user's browser.Changes
resolveBrowserReachableAgentServerBaseUrl()and use it for agent-server client options.Validation
npm test -- __tests__/api/agent-server-config.test.ts __tests__/api/agent-server-client-options.test.ts __tests__/api/cloud/proxy.test.ts __tests__/api/device-flow-client.test.tsnpm run typecheck && npm run build🐳 Docker images for this PR
• GHCR package: https://github.com/OpenHands/agent-canvas/pkgs/container/agent-canvas
ghcr.io/openhands/agent-canvasghcr.io/openhands/agent-server:1.23.0-pythonopenhands-automation==1.0.0a3d7c16e2e726f719b2c240ddf5c143e6f98ac0dadPull (multi-arch manifest)
# Multi-arch manifest — Docker automatically pulls the correct architecture docker pull ghcr.io/openhands/agent-canvas:sha-d7c16e2Run
All tags pushed for this build
About Multi-Architecture Support
sha-d7c16e2) is a multi-arch manifest supporting both amd64 and arm64sha-d7c16e2-amd64) are also available if needed