Can`t use openclaw windows via gateway is behind an oauth proxy

[xrow]

I get a 403. No way to by pass. I use https://github.com/oauth2-proxy/oauth2-proxy.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 15, 2026, 1:46 PM ET / 17:46 UTC.

Summary
Keep open: OAuth2-proxy access is not demonstrably implemented on main. The same author's earlier report was closed for inactivity, not resolved, and the new screenshot establishes a reachability warning rather than a failed authenticated connection.

Reproducibility: unclear. Source explains the visible unauthenticated HTTP-probe warning, but the report lacks the version, proxy configuration, and actual connection result needed to reproduce the claimed access failure.

Ways to help us reproduce this

• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should Companion add OAuth2-proxy sign-in support, or explicitly guide these deployments toward an independently authenticated Gateway access path?	Clarify supported access first: Establish the deployed proxy contract and actual connection failure, then provide precise in-product guidance before committing to OAuth session support.

Why: The repository defines Gateway pairing and SSH forwarding, but no OAuth-proxy session contract; selecting a new credential and reconnect lifecycle requires product and security intent.

Next step
Resolve the supported authentication boundary using the Companion version, redacted proxy settings, and Save & connect result before scoping implementation.

Security
None.

Review details

Best possible solution:

Provide an explicit, secure remote-access flow with actionable inline guidance, keeping proxy authentication separate from Gateway pairing and avoiding generic shell hooks or authentication bypasses.

Do we have a high-confidence way to reproduce the issue?

Unclear. Source explains the visible unauthenticated HTTP-probe warning, but the report lacks the version, proxy configuration, and actual connection result needed to reproduce the claimed access failure.

Is this the best way to solve the issue?

Unclear. OAuth-proxy sign-in is a new capability; changing the reachability check alone would not authenticate the WebSocket connection.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The Companion version, proxy authentication configuration, and actual Save & connect result remain unspecified; the HTTP warning alone cannot locate the connection failure.

Codex review notes: model internal, reasoning medium; reviewed against 3c43751b2bac.

Label changes

Label changes:

• add P2: This is a concrete access limitation in an advanced reverse-proxy deployment, without evidence of a regression in the supported default setup.
• add impact:auth-provider: The requested access path requires authentication at a proxy before Gateway authentication can begin.
• add issue-rating: 🦐 gold shrimp: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This is a concrete access limitation in an advanced reverse-proxy deployment, without evidence of a regression in the supported default setup.
• impact:auth-provider: The requested access path requires authentication at a proxy before Gateway authentication can begin.

Evidence reviewed

What I checked:

• Screenshot inspected: The downloaded screenshot shows the Add Gateway form, an empty shared-token field, an enabled Save & connect button, and 'Gateway responded with 403'. It does not show the result of an authenticated WebSocket attempt.
• Warning comes from an unauthenticated probe: RunConnectivityTestAsync uses a new HttpClient to GET the endpoint and then /health without proxy credentials. Non-success status codes produce the screenshot's warning. The separate save handler invokes the direct-connect service without treating that warning as a connection gate. (src/OpenClaw.Tray.WinUI/Pages/ConnectionPage.xaml.cs:2736, 3c43751b2bac)
• Current transport authentication boundary: The shared WebSocket transport sets Origin and optionally HTTP Basic Authorization from embedded URL credentials. This path does not perform OAuth browser sign-in or transfer a browser session cookie. GatewayRecord separately stores Gateway shared/bootstrap credentials and SSH configuration. (src/OpenClaw.Shared/WebSocketClientBase.cs:270, 3c43751b2bac)
• Existing authentication tests: URL-helper tests cover supported schemes, credential extraction, Basic-auth encoding, and removal of credentials from normalized URLs. These establish a narrower contract than OAuth2-proxy sign-in. (tests/OpenClaw.Shared.Tests/GatewayUrlHelperTests.cs:59, 3c43751b2bac)
• Earlier report supplies useful deployment context: feature: Add new functionality to connect options #766 (feature: Add new functionality to connect options) is by the same author and explicitly describes OAuth2-proxy, a Layer 7 load balancer, unavailable SSH, and a Kubernetes forwarding alternative. Its final comment closed it for inactivity; no implemented fix was established. The broader lifecycle-hook request is outside this issue's narrower proxy-access report.
• Canonical and release checks: An exact OAuth2-proxy PR search returned no results. The checkout matches the supplied main SHA and tag v2026.9.4; GitHub identifies that tag as the latest release, published September 15, 2026. No fixing release or merged implementation was established. (3c43751b2bac)

Likely related people:

• shanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• bkudiess: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.