GitHub Repo
Firecrawl Proposes Zero Data Retention Fix for Research and Developer Search
On October 25, a Firecrawl contributor proposed a patch noting that teams enforcing zero data retention only for scraping could still retain data on some search paths. The proposal would update database fields, logs, and upstream headers, but had not been merged as of the review.
A gap has emerged in how Firecrawl’s zero data retention setting propagates across services. On October 25, project contributor mogery opened PR #5394, explaining that research agents previously determined whether to enable zero data retention (ZDR) based only on search mode. As a result, if a team configured only scrapeZDR: "forced", research, GitHub, developer, and government searches could still follow the full data retention process. This is the proposal author’s description of the existing behavior; there is no public evidence of how many customers were affected or of actual data retention incidents. Patch proposal
The issue involves two separate controls. The official search documentation explains that the enterprise parameter controls the search portion and is separate from the scraping-side zeroDataRetention option. End-to-end ZDR requires both Firecrawl and upstream search providers to retain neither queries nor results, while anonymized mode allows upstream caching of anonymized queries. For teams building research agents or RAG pipelines, verifying which mode applies at each stage of a request directly affects data processing boundaries. Search and ZDR documentation
The proposal switches to an existing settings resolver so that if either scraping or search is forced to use ZDR, retention limits apply to the relevant research controllers. Specific changes include masking requests.target_hint, clearing or masking sensitive fields in research tables, scheduling cleanup jobs, and adding a ZDR marker to logs so filters can remove them. Headers sent to research, developer, and government services would also change to firecrawl-zero-data-retention: true. Implementation details
From an engineering perspective, this is a reminder for teams to verify retention policies at every stage—entry point, database, logs, and upstream services—instead of checking only the client flag. The author has listed new tests, but the page also shows five failing deep research tests, and it is not yet possible to determine whether they are related to the patch. As of the review, the PR remains open, with no confirmed release containing the fix or evidence of deployment. Teams should track its merge and rollout status, then validate field masking and upstream headers with a configuration that forces scraping-only ZDR. Test and proposal status