Pi 401s on first request — Pi picks an env-backed built-in provider (e.g. huggingface via HF_TOKEN) instead of our configured Databricks provider

[JamesHWade]

ucode pi configures successfully but validation immediately fails:

ERROR Pi: 401 "Invalid username or password."
ERROR Pi validation failed — config reverted.

Root cause

build_runtime_env in src/ucode/agents/pi.py copies the full os.environ into Pi's subprocess. If the user has any env var that Pi's pi-ai package recognizes as auth for a built-in provider — e.g. HF_TOKEN for huggingface, OPENAI_API_KEY for openai, GEMINI_API_KEY for google — then authStorage.hasAuth(provider) returns true for that built-in (pi-ai/dist/env-api-keys.js).

Pi's findInitialModel (core/model-resolver.js) walks defaultModelPerProvider in order looking for the first available model. Built-in providers like huggingface appear before our databricks-claude (which isn't in defaultModelPerProvider), so Pi picks the built-in model and routes the request to e.g. https://router.huggingface.co/v1. With an unrelated/invalid HF token, the response is 401 "Invalid username or password" — which surfaces as the Pi validation failure.

The original header-conflict hypothesis was wrong: authHeader: true is correct, and both X-Api-Key and Authorization: Bearer to /ai-gateway/anthropic returns 200 (verified by curl). The issue is which provider Pi picks, not how it authenticates.

Fix

Write ~/.pi/agent/settings.json next to models.json with defaultProvider and defaultModel set to our chosen Databricks provider/model. Pi's findInitialModel step 3 reads these from settings and uses them before falling through to the env-keyed built-in providers.

Repro

1. export HF_TOKEN=hf_anything (or any other built-in provider env var)
2. ucode pi → validation 401s
3. Unset the env var → validation succeeds