Decide deliberately: blanket /static/ auth exemption (and stop narrow allowlists that read as boundaries)

[jaylfc]

Is a blanket /static/ auth exemption the boundary we want?

Surfaced by CodeRabbit on PR #2145 (closed as a no-op) and verified in the code.

tinyagentos/auth_middleware.py:

• line 170: EXEMPT_PREFIXES = ("/static/", "/desktop/", "/chat-pwa/", "/ws/", "/shortcut/", "/api/peer/")
• line 275: if path in EXEMPT_PATHS or any(path.startswith(p) for p in EXEMPT_PREFIXES): return True

So every asset under /static/ is served without authentication, and any attempt to
add narrow per-file exemptions there is dead code that reads as a security boundary while
being none. That is how #2145 came to exist.

This is a question, not a defect report

A broad static exemption is normal and probably correct: the login page itself is served
from /static/, so requiring auth to fetch it would be circular. Removing the prefix (as
the bot suggested) would break login unless every asset the unauthenticated shell needs is
enumerated first.

What is worth deciding deliberately:

1. Does anything sensitive live under /static/ today, or could it later? Built SPA
   bundles and icons are fine. User-uploaded content, exports, or generated artifacts would
   not be. Confirm nothing writes user data under that root, and add a test that fails if
   something starts to.
2. Should the comment tell the truth? Whatever we decide, the file should say plainly
   that /static/ is public, so the next person does not add a "narrow" allowlist that
   does nothing.
3. Optional: split /static/public/ (unauthenticated shell assets) from anything else, so
   the boundary is structural rather than a convention.

Not urgent

No known exposure - this is the current, long-standing behaviour and nothing indicates
sensitive content under that path. Filing so the decision is made on purpose rather than
inherited, and so the misleading-comment trap does not recur.