USR369 correctly rejected the sessionStorage+prompt fix -- asking for the token on every visit isn't a fix, and per direction to 'search the web' / 'how do other systems do it', researched current practice (OWASP, PHP manual, Auth0/FusionAuth guidance): the standard answer is a server-side HttpOnly session cookie set by a real login page -- JavaScript can never read it, so it can't be exposed via page source or XSS, and the browser just sends it automatically after one login. Built: (1) auth-lib.php -- added cai_start_session()/extended cai_check_token() to ALSO accept a valid PHP session, purely additive, every existing token-param caller (API calls, this Claude session, Claude Code, etc.) works identically to before. (2) login.php -- one-time form, POSTs token, validates via cai_check_token(), sets ['cai_authed'] + session_regenerate_id(), redirects back. (3) DISCOVERED while wiring this up: file_write_web.php -- the endpoint every Save action actually hits -- had the raw admin token hardcoded directly in server-side PHP, completely bypassing auth-lib.php (a straggler that missed the 08/18/26 Phase 2 migration every other endpoint got). Same risk class as the prior K372/K373 token-in-files incidents, plus meant every future rotation required remembering to hand-edit this one file. Migrated it to use cai_check_token() too. (4) fix-log.html -- removed every token/TOKEN reference entirely, including the sessionStorage/prompt version from the previous fix; fetch calls now carry no auth of any kind, relying entirely on the browser's session cookie; added isAuthError()/redirectToLogin() so an unauthenticated visit bounces to login.php once instead of failing silently.