Instagram: the reels feed (/reels/) is not collected, unlike every other listing page
Status: I decided this as a tradeoff to allow collecting individual reels via /reels/<code>/
What happens
Browsing instagram.com/reels/ collects nothing. instagram.com/reels/ always redirects to a specific reel and is thus not currently differentiable.
In the code, reels is absent from the views_serving_own_posts allowlist in modules/instagram.js, so the feed's /graphql/query responses are dropped.
Why it is excluded
Every other listing page displays what it delivers (I actually am not seeing any pre-loading at the moment in tests even!). An explore grid fetches 18 posts and puts 18 posts on screen; capturing the response captures what the user saw.
The reels feed does not. It delivers a batch of ~7-9 reels and shows one at a time, the rest being lookahead. Watch two and navigate away, and seven reels nobody saw would land in the dataset which are indistinguishable from ones that were watched by Zeeschuimer.
A second problem compounds it: instagram.com/reel/<code>/ — the format share links use — redirects to /reels/<code>/ (verified 2026-08-26). So opening somebody's shared reel puts you on the feed, at a URL indistinguishable from "I am browsing and this is reel #4". Allowlisting reels would therefore turn every opened share link into a nine-post harvest.
Why it is not simply fixed
The information needed — which reels were actually scrolled into view — never reaches the code that decides.
But, the signal does exist elsewhere. The reels feed rewrites the address bar to each reel's code as it comes into view, and js/zs-background.js already observes tab URL changes (that is how nav_index works). It is not currently plumbed through to modules.
Possible solution
Turn a response-driven decision into a view-driven one, for this surface only:
- When a reels batch arrives,
capture() stashes the items in a module-scoped cache keyed by shortcode instead of returning them.
- Whenever a later request is seen while the tab is at
/reels/<code>/, emit the cached item for <code> if it has not been emitted yet.
Open questions before attempting it:
- Does anything fire per reel? Step 2 needs some request while each reel is on screen. Instagram sends
logging_client_events during interaction, which capture() already sees and discards early, so the hook probably exists.
capture() has no tab id. A module-scoped cache would be shared across tabs and could mis-attribute. This may not super matter, but we do use tabs for our unique ids (and whether we recollect a post).- Cache lifetime. Entries for reels that are never scrolled should probably expire, but not sure how we do that.
- Is it worth it for one surface? It's seems like it might be a lot.
Instagram: the reels feed (
/reels/) is not collected, unlike every other listing pageStatus: I decided this as a tradeoff to allow collecting individual reels via
/reels/<code>/What happens
Browsing
instagram.com/reels/collects nothing.instagram.com/reels/always redirects to a specific reel and is thus not currently differentiable.In the code,
reelsis absent from theviews_serving_own_postsallowlist inmodules/instagram.js, so the feed's/graphql/queryresponses are dropped.Why it is excluded
Every other listing page displays what it delivers (I actually am not seeing any pre-loading at the moment in tests even!). An explore grid fetches 18 posts and puts 18 posts on screen; capturing the response captures what the user saw.
The reels feed does not. It delivers a batch of ~7-9 reels and shows one at a time, the rest being lookahead. Watch two and navigate away, and seven reels nobody saw would land in the dataset which are indistinguishable from ones that were watched by Zeeschuimer.
A second problem compounds it:
instagram.com/reel/<code>/— the format share links use — redirects to/reels/<code>/(verified 2026-08-26). So opening somebody's shared reel puts you on the feed, at a URL indistinguishable from "I am browsing and this is reel #4". Allowlistingreelswould therefore turn every opened share link into a nine-post harvest.Why it is not simply fixed
The information needed — which reels were actually scrolled into view — never reaches the code that decides.
But, the signal does exist elsewhere. The reels feed rewrites the address bar to each reel's code as it comes into view, and
js/zs-background.jsalready observes tab URL changes (that is hownav_indexworks). It is not currently plumbed through to modules.Possible solution
Turn a response-driven decision into a view-driven one, for this surface only:
capture()stashes the items in a module-scoped cache keyed by shortcode instead of returning them./reels/<code>/, emit the cached item for<code>if it has not been emitted yet.Open questions before attempting it:
logging_client_eventsduring interaction, whichcapture()already sees and discards early, so the hook probably exists.capture()has no tab id. A module-scoped cache would be shared across tabs and could mis-attribute. This may not super matter, but we do use tabs for our unique ids (and whether we recollect a post).