# Aliyun key hot reload

This patch closes two key-rotation gaps in the production Chat API without
storing any credential in Git:

1. `video_gateway_api_key()` prefers a protected `*_API_KEY_FILE` on every
   call, so the AI skill router cannot keep using the startup-cached value.
2. `CodexAppServerProcess` fingerprints the protected provider key before
   every request. When the file changes and no request is pending, it replaces
   only the persistent Codex child and resumes the existing thread.

Production base hashes used by this patch:

- `chat_api.py`: `de81004c50a96fdf2e0064340edab213139da6ef304014c1586a4059871a8a1b`
- `codex_app_server_runtime.py`: `13c4463c6226840ae1a751279b4ec830796fb8cb46e2491f245bbdfebc71dfb9`

Deployed hashes on 2026-09-08:

- `chat_api.py`: `878e4e0d4c7e5b91190f53b64dccca3154fa3a189ea006d2182d0930a9079c4f`
- `codex_app_server_runtime.py`: `1ba04cbd15842114c77e89e71c7f36a43a24bc77bac22fd88eeb5d714b573cb3`

The deployment was gated on zero queued/running durable tasks and zero real
Chat API requests in the previous five minutes. A backup was created at
`/opt/dalongxia-chat-api/backups/aliyun-key-hot-reload-mLOvGl` before the
service restart.

Verification:

- the supplied key file fingerprint matched the protected server key file;
- a direct `qwen3-vl-plus` request returned HTTP 200;
- the production health endpoint returned HTTP 200 after restart;
- the next two Codex shadow records completed successfully, while the three
  immediately preceding records had failed with `CodexAppServerError`;
- no post-deployment `InvalidApiKey` or `API-key is blocked` error appeared.