CLI & agent: support custom HTTP request headers (auth behind a reverse proxy / Cloudflare Access)

[dkhodakivskyi]

Summary

When cix is self-hosted behind an authenticating reverse proxy / Zero Trust gateway (e.g. Cloudflare Access, oauth2-proxy, Authelia), the web dashboard works (interactive browser SSO) but the CLI and AI-agent tooling cannot reach the server unless the client's source IP is allow-listed (VPN). Please allow the CLI/agent to send user-configured custom HTTP headers on every request, so they can satisfy the proxy (e.g. a Cloudflare Access service token) in addition to the existing cix API key.

Background — two independent auth layers

1. Edge / proxy decides whether the request reaches the origin. Cloudflare Access is satisfied by interactive SSO, an IP-allowlist bypass, or a service token sent as CF-Access-Client-Id + CF-Access-Client-Secret headers.
2. Origin / cix then authenticates with Authorization: Bearer cix_….

The browser does (1) via SSO, so the dashboard is fine. The CLI/agent send only the Bearer (layer 2) and have no way to satisfy layer 1 except an allow-listed IP — so off-VPN they're blocked at the edge (302 to login / 403) and never reach cix.

Proposed improvement

Allow arbitrary, user-configured request headers in the CLI config (and the agent/plugin), e.g. ~/.cix/config.yaml:

api:
  url: https://cix.example.com
  key: cix_xxx
  headers:                                    # NEW: attached to every request
    CF-Access-Client-Id: "<client-id>.access"
    CF-Access-Client-Secret: "${CIX_CF_ACCESS_SECRET}"   # env expansion; no plaintext secret

The client then sends the service-token headers (→ passes Cloudflare Access) plus the cix Bearer (→ authenticates to cix). Cloudflare validates and strips the CF-Access-* headers at the edge, so the origin still only sees the Bearer — cix needs no knowledge of Cloudflare.

Why it's worth it

• Not Cloudflare-specific: unlocks any authenticating reverse proxy (oauth2-proxy, Authelia, an SSO/mTLS-terminating LB that expects an injected header, corporate proxies).
• Small surface: "attach these configured headers to outbound requests" in the CLI/agent HTTP client — no server-side changes.
• The proxy side already supports this (e.g. CF Access service tokens); the only missing piece is the client being able to send the headers.

Notes

• Header values can be secrets → support env-var expansion and never log custom header values.
• Opt-in; absent config = current behavior.
• For human users a short-lived per-user proxy login is preferable; service tokens suit machine/agent clients — both just need the client to send headers.
• Not requested: cix validating the CF Access JWT (Cf-Access-Jwt-Assertion) itself — heavier and CF-specific; configurable headers is the minimal, general solution.