The whole bug: Slingshot's batch proxy puts the authorization field straight into the upstream Authorization header, so it must include the 'Bearer ' scheme. We were sending the bare service-auth token, which made the proxy fail with the opaque 400 'oop/sorry' - which I wrongly read as auth forwarding being broken. Proven against the live proxy: bare token -> 400 oop/sorry; 'Bearer <jwt>' -> 200 with hydrated records. So personalized feeds work through the batch proxy after all. - hydrateFeedSkeleton now prefixes 'Bearer ' on the authorization value - buildCustomFeed switched back to the batch proxy (server-side, so it works on web too - no CORS wall like a direct generator call) forwarding the viewer's service-auth token Logged-in personalized feeds (For You) now load through microcosm, no AppView.