Training a video LoRA from the Characters page returned:

  POST /v1/loras/train -> 401: Invalid API key. Provide a valid Bearer token.

CoderAI gates every /v1 endpoint through the same dependency and makes NO
exemption for loopback, so the bundled tools — which call 127.0.0.1 from inside
the same container — need a Bearer token exactly like a remote client. The
container launches this tool without --api-key and its saved config had none, so
there was no token to send. Nothing was wrong with the training request itself.

Fourteen call sites each built their client from default_args.api_key directly.
They now go through one resolver with a stated order: the running options (set by
--api-key, a saved config, or the Connection card) → the config file on disk →
CODERAI_API_KEY in the environment, which is how a launcher can supply it without
a config edit. A blank value is treated as absent rather than sent as "Bearer ",
which would have failed in a more confusing way.

A 401 now says what to do — where to put a key in THIS tool — instead of echoing
a server message that tells an operator nothing about this UI.

The immediate fix needs no rebuild: paste the key into the Connection card on the
Run page and press Save config. That writes township_config.json and updates the
running options, so the next action authenticates.

11 tests, including that no call site reads default_args.api_key any more.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY