Symptom

Reported by Ben: open the dashboard with an expired/missing session while on /models (or any analytics-style page), get bounced through Nous Portal's OAuth screen, and land on $DOMAIN/api/analytics/models?days=30 — raw JSON in the address bar instead of the dashboard.

Reproduces deterministically: whichever /api/* call a page fires first on mount owns the redirect race, so the bad landing URL varies by page but the bug fires every time.

Root cause

Single bug at two boundaries:

1. Gate side (_safe_next_target in hermes_cli/dashboard_auth/middleware.py): the gated middleware computes next= from the request's own path. When an unauthenticated SPA fetch hits a gated endpoint, the path going into next= is the API URL the SPA was calling.

2. Callback side (_validate_post_login_target in hermes_cli/dashboard_auth/routes.py): only filters out /login, /auth/, and /api/auth/. Any other /api/* value is accepted as same-origin.

End-to-end flow:

ModelsPage.tsx mounts
  → api.getModelsAnalytics(30)  →  GET /api/analytics/models?days=30
  → 401 { login_url: "/login?next=%2Fapi%2Fanalytics%2Fmodels%3Fdays%3D30" }
  → web/src/lib/api.ts: window.location.assign(login_url)
  → /login → /auth/login (stores next in PKCE cookie)
  → Portal OAuth dance
  → /auth/callback (reads next= from cookie, validates as "same-origin", redirects)
  → /api/analytics/models?days=30  →  raw JSON in address bar

The SPA's own sessionStorage["hermes.lastLocation"] fallback in api.ts already saves the actual browser location, so dropping the server-stamped next= on /api/* requests doesn't lose any UX — the SPA recovers the deep link itself.

Fix

Both validators now reject /api/* targets in addition to the existing /login, /auth/, /api/auth/ exclusions. The match is anchored (decoded == "/api" or decoded.startswith("/api/")) so SPA route lookalikes like /apidocs or /api-keys remain valid landing targets.

Why both validators get the same fix: either layer alone is sufficient; pairing them means a regression in one is caught by the other. The callback-side validator is the load-bearing one (it's the last line of defence against a legacy cookie / regressed middleware / attacker-crafted /auth/login?next=/api/...), and the gate-side fix means the SPA's 401 handler navigates to a bare /login (clean, no useless redirect parameter) in the common case.

Tests

Added to tests/hermes_cli/test_dashboard_auth_401_reauth.py:

• TestApi401Envelope: rewrote test_login_url_carries_next_for_deep_api_path (which had locked in the pre-fix behaviour) into test_login_url_drops_next_for_deep_api_path, plus added test_login_url_drops_next_for_analytics_path as the specific repro for Ben's report.
• TestNextSameOriginValidation: test_safe_next_validator_rejects_api_paths (covers /api, /api/analytics/models, /api/sessions, /api/config, /api/status) + test_safe_next_validator_does_not_reject_api_prefix_lookalikes (covers /apidocs, /api-keys).
• TestAuthCallbackNext: end-to-end test_callback_with_api_next_lands_at_root drives /auth/login?next=/api/analytics/models?days=30 through to the callback and asserts the user lands at /, not the API URL.
• TestValidatePostLoginTarget: new class covering the callback-side validator directly, including the URL-encoded %2Fapi%2F... form the PKCE cookie actually carries.

Verification

• Targeted: bash scripts/run_tests.sh tests/hermes_cli/test_dashboard_auth_401_reauth.py → 36/36 pass.
• Wider: bash scripts/run_tests.sh tests/hermes_cli/ → 288 files, 5,938 tests, 100% pass.
• Mutation-tested: reverted both validators in place, ran the file, saw exactly the 5 new/rewritten /api/* assertions fail and the 31 other tests remain green. Each fix layer is independently tested.

Files

No SPA changes — sessionStorage["hermes.lastLocation"] was already saving the right value; this PR just stops the server from emitting a useless (and harmful) override.