LOG-005 is a WordPress cookie bug that looked like three different problems depending on which browser you tried it in, and was actually one line of missing config.
The symptom
Logging in worked. Landing on the dashboard worked. Clicking almost anything else sent you straight back to the login screen — as if the session had never existed. It wasn’t credentials, it wasn’t rate limiting, and it wasn’t a certificate problem; the actual login step always succeeded. Whatever was breaking happened after that, on every request that followed.
Ruling things out
The obvious suspects went first. Not a caching layer serving a logged-out page — disabling cache made no difference. Not a cookie being rejected outright — the browser’s own cookie inspector showed something being set. What it showed, once we actually looked closely instead of just confirming a cookie existed, was duplicates: more than one wordpress_sec_ cookie, scoped to different paths, fighting over the same request.
The actual cause
WordPress scopes its auth cookies with two constants, COOKIEPATH and SITECOOKIEPATH. On this install they were set to the same value — which, per WordPress’s own cookie logic, means the admin authentication cookie silently falls back to a third constant, PLUGINS_COOKIE_PATH, that nothing here had ever defined. An undefined path constant doesn’t throw an error. It just resolves to something WordPress didn’t intend, and the auth cookie ends up scoped somewhere the admin area never checks. The login form sets the cookie correctly. The next request looks in the wrong place for it, finds nothing, and bounces you back to login — which looks, from the outside, exactly like the login never worked at all.
The fix was two constants that should have existed from the start:
define('ADMIN_COOKIE_PATH', '/');
define('PLUGINS_COOKIE_PATH', '/');One more thing turned up in the same pass: the account we were actually testing with didn’t hold the Administrator role, which would have produced a related-looking but separate failure once the cookie issue was fixed. Both had to be true before login actually worked end to end.
Why this one was worth logging
Nothing about the symptom pointed at cookie path scoping. It looked like a credentials problem, then a caching problem, then a certificate problem, and was actually a WordPress internal fallback nobody had configured for a domain-wide login. The lesson isn’t the fix — it’s that “logging in works, everything after doesn’t” is a session-scoping question before it’s anything else.