Feature Request: Cloudflare Access / Zero Trust support (custom HTTP headers)

[D3rPaPaH0d3n]

Problem

When running an OpenClaw gateway behind a Cloudflare Tunnel with Zero Trust Access policies, ClawControl cannot connect because Cloudflare redirects all unauthenticated requests to a browser-based SSO login page (HTTP 302).

Since ClawControl is a native app (Electron/Capacitor), it cannot follow browser-based authentication flows.

Proposed Solution

Add support for Cloudflare Access Service Tokens in the connection settings. This would allow users to configure two custom HTTP headers that are sent with every WebSocket connection and HTTP request:

• CF-Access-Client-Id
• CF-Access-Client-Secret

These headers bypass the browser-based login and authenticate the request directly with Cloudflare Access.

Implementation Ideas

1. Add two optional fields in the Settings/Connection page: CF-Access-Client-Id and CF-Access-Client-Secret
2. If set, include these headers in the WebSocket upgrade request and any HTTP calls to the server
3. Alternatively, support a generic "Custom Headers" field (key-value pairs) which would also cover other reverse proxy auth scenarios (e.g., Authentik, Authelia, Traefik Forward Auth)

A generic custom headers approach would be more flexible and cover more use cases.

Context

• Cloudflare Zero Trust is commonly used to secure self-hosted services exposed via Cloudflare Tunnel
• Service Tokens are the official machine-to-machine auth method: https://developers.cloudflare.com/cloudflare-one/identity/service-tokens/
• Many OpenClaw users likely expose their gateway via Cloudflare Tunnel for remote access

Environment

• ClawControl v1.7.1 (Android / Play Store)
• OpenClaw v2026.4.1
• Cloudflare Tunnel + Zero Trust Access active on the gateway domain