Problem
Original text:
「limiter對於login, logout的指令不要檔」
— Source: 使用者 2026-08-19 對話（逐字，含原文的「檔」字）
limiter 閂鎖期間，認證與 session 類請求（/login、/logout、OAuth token refresh）不應被延遲。認證恰好是使用者被閂住時最需要能運作的操作。
Type
feature（hardening）
Expected
認證／session 類請求一律立即轉發，不受 limiter 閂鎖與 rejected-aware hold 影響。豁免判定必須 fail-safe —— 判不出來時傾向不擋認證。
Actual
plugins/claude-hot-limit/proxy/rate-limit-proxy.py 的 _handle() 對 self.path 零判斷，無條件對每一個經過 proxy 的請求呼叫 limiter_admission()（以及 schedule_admission()）：
limiter_held_ms = limiter_admission(flag_dir, tier=cached_plan_tier())
sched_held_ms = 0 if limiter_held_ms else schedule_admission(flag_dir)
url = self._upstream().rstrip("/") + self.path # ← path 在 admission 之後才被讀沒有任何路徑白名單或豁免機制。
目前是潛在風險，不是已發生的阻擋（查證結果）
必須誠實區分：實測顯示認證流量目前並未經過 proxy。
- 近 16 小時 6,942 筆
rate-state.jsonl 記錄中，model 欄位為空的有 0 筆。
_record_state() 會無條件寫入 "model": req_model（None 也寫成 null），所以「0 筆空 model」代表這段期間經過 proxy 的全部是 Messages API 請求。- 因此
/login、/logout 的流量並未出現在 proxy 上，今天不會被閂鎖延遲。
Impact
風險仍然成立，理由有三：
- 無版本承諾：請求是否走
ANTHROPIC_BASE_URL 是 Claude Code 的內部實作細節，可隨時改變且不會有通知。一旦 auth 或 OAuth token refresh 走上這條路徑，閂鎖期間會被硬壓一個完整的 hold cap（預設 90 秒、上限 240 秒）。
- 可能升級為認證失敗：90–240 秒的延遲可能超過 client 端逾時，讓「變慢」惡化成「登入失敗」。
- 與 2026-08-18 的 C1 事故同一形狀：復原路徑本身被保護機制擋住。C1 是「建立
limiter-off 反而讓中斷變永久」，本 issue 是「被閂住時連重新登入都可能被拖住」。防護機制不該擋住用來解除防護的動作。
附帶的可觀測性缺口
proxy 的 access log 被關閉（log_message 覆寫為 pass），且 state record 不含 path，因此無法事後判斷哪些路徑經過 proxy。上面「0 筆空 model」是間接推論，不是直接觀測。
要驗證豁免是否真的生效，需要某種形式的路徑可見度（例如把 path 或其分類寫進 state record）。這應視為本 issue 的前置或同批工作 —— 否則修完也無法證明有效。
Refs
Clarity Surface（idd-clarify run 2026-08-19T03:2xZ）
| Type |
Source |
Question for you |
Status |
| terminology |
「認證／session 類請求一律立即轉發」 |
「session 類請求」到底涵蓋哪些？只有 /login /logout，還是也含 OAuth token refresh、organization/profile 查詢這類非 Messages 的請求？ |
surfaced |
| ambiguity |
「豁免判定必須 fail-safe —— 判不出來時傾向不擋認證」 |
豁免要用什麼判？(a) path 白名單、(b) request body 沒有 model 欄位、還是 (c) 明確的 endpoint 清單？若選 (b)，任何格式異常的請求都會被豁免——這個當成 bypass 可以接受嗎？ |
surfaced |
| missing-context |
「近 16 小時 6,942 筆記錄中 model 為空的有 0 筆」 |
既然目前沒有任何認證流量經過 proxy，這個豁免要怎麼測？要先做附帶提到的路徑可見度（把 path 寫進 state record）才有辦法驗證嗎，還是先用單元測試假造請求就好？ |
surfaced |
Problem
limiter 閂鎖期間，認證與 session 類請求（
/login、/logout、OAuth token refresh）不應被延遲。認證恰好是使用者被閂住時最需要能運作的操作。Type
feature（hardening）
Expected
認證／session 類請求一律立即轉發，不受 limiter 閂鎖與 rejected-aware hold 影響。豁免判定必須 fail-safe —— 判不出來時傾向不擋認證。
Actual
plugins/claude-hot-limit/proxy/rate-limit-proxy.py的_handle()對self.path零判斷，無條件對每一個經過 proxy 的請求呼叫limiter_admission()（以及schedule_admission()）：沒有任何路徑白名單或豁免機制。
目前是潛在風險，不是已發生的阻擋（查證結果）
必須誠實區分：實測顯示認證流量目前並未經過 proxy。
rate-state.jsonl記錄中，model欄位為空的有 0 筆。_record_state()會無條件寫入"model": req_model（None也寫成null），所以「0 筆空 model」代表這段期間經過 proxy 的全部是 Messages API 請求。/login、/logout的流量並未出現在 proxy 上，今天不會被閂鎖延遲。Impact
風險仍然成立，理由有三：
ANTHROPIC_BASE_URL是 Claude Code 的內部實作細節，可隨時改變且不會有通知。一旦 auth 或 OAuth token refresh 走上這條路徑，閂鎖期間會被硬壓一個完整的 hold cap（預設 90 秒、上限 240 秒）。limiter-off反而讓中斷變永久」，本 issue 是「被閂住時連重新登入都可能被拖住」。防護機制不該擋住用來解除防護的動作。附帶的可觀測性缺口
proxy 的 access log 被關閉（
log_message覆寫為pass），且 state record 不含path，因此無法事後判斷哪些路徑經過 proxy。上面「0 筆空 model」是間接推論，不是直接觀測。要驗證豁免是否真的生效，需要某種形式的路徑可見度（例如把 path 或其分類寫進 state record）。這應視為本 issue 的前置或同批工作 —— 否則修完也無法證明有效。
Refs
Clarity Surface（idd-clarify run 2026-08-19T03:2xZ）
/login/logout，還是也含 OAuth token refresh、organization/profile 查詢這類非 Messages 的請求？model欄位、還是 (c) 明確的 endpoint 清單？若選 (b)，任何格式異常的請求都會被豁免——這個當成 bypass 可以接受嗎？