Config: demo=True + base_url override silently produces split REST/WS environment #239

Summary

Money risk. If a caller sets demo=True while also passing base_url (or sets KALSHI_DEMO=true together with KALSHI_API_BASE_URL=<prod>), setdefault leaves base_url at the explicit value but still pins ws_base_url to DEMO_WS_URL. REST hits production (real money) while WS data feeds come from demo. A WS-driven strategy can place live orders against signals derived from a demo book.

Symmetric case: base_url=DEMO_BASE_URL with demo=False (default) leaves ws_base_url at production.

KalshiConfig.__post_init__ validates the two URLs independently and never cross-checks that REST and WS resolve to the same Kalshi environment.

Location

• kalshi/client.py:88-92 — constructor setdefault logic
• kalshi/async_client.py:88-92 — mirror
• kalshi/client.py:139-141 — from_env
• kalshi/async_client.py:170-172 — mirror

Evidence

if base_url:
    config_kwargs["base_url"] = base_url
if demo:
    config_kwargs.setdefault("base_url", DEMO_BASE_URL)
    config_kwargs.setdefault("ws_base_url", DEMO_WS_URL)

# from_env:
demo = os.environ.get("KALSHI_DEMO", "").lower() == "true"
base_url = os.environ.get("KALSHI_API_BASE_URL")
client = cls(auth=auth, demo=demo, base_url=base_url, **kwargs)

Recommended fix

Reject mixed REST/WS environments in KalshiConfig.__post_init__ (or in the client constructor) unless an explicit allow_mixed_env=True is set; alternatively raise when demo=True is combined with a non-demo base_url instead of silently honoring base_url and overriding only ws_base_url. Add an integration test for the env-var combination.

Severity & category

high / correctness, security