[FEATURE] Track blocked/unreachable sources across a session so negative research findings aren't drawn from pages that never loaded

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet. Related issues are about which domains the egress proxy blocks (#96260, #95671, #93512); this one is about what happens to the fact that something was blocked.
• [x] This is a single feature request

Problem Statement

When a fetch is blocked, the individual tool result says so (EGRESS_BLOCKED). But in research work that fact rarely survives to the conclusion. Across dozens of searches, subagents and workflow stages, "page X could not be opened" gets summarized into "nothing was found". A negative literature search then gets read as evidence that something does not exist.

This happened in my research workspace, with real consequences. My cloud sessions' network policy blocked arXiv, Springer, Crossref, OpenAlex, Semantic Scholar, Wikipedia and most journal sites. The resulting failures, all recorded in the repo:

• A three-vortex result was concluded to be unique after a search whose own log says "Blocked: … Most journals." The closed form was later found in Gröbli (1877) and Kimura (1987). The project had already publicly called five results "the first public source of these formulas". An audit found zero were new (identities/NOVELTY-AUDIT.md).
• The repo's research ledger now carries a standing rule against agents that search sites which never loaded "and then write 'I did not find it' as if those sites had loaded" (RESEARCH.md:306).
• Several later novelty statements had to be narrowed after review because they rested on papers seen only through search snippets.

I documented 80 incidents like this in a case study, with an incident dataset and an independent coding check: Eighty Failures: Error Modes and Controls in AI-Assisted Mathematical Research (PDF, CSV). The blocked-source-read-as-absence pattern was the single most damaging one. Section 4.1 covers that case, and Section 7.2 lists the tooling changes that would have prevented it, including this one.

Proposed Solution

Make "unreachable" a first-class, persistent result rather than a per-call error:

1. A session-level record of unreachable sources. The harness already knows every blocked or failed fetch. Keep a running list (URL or host, reason, time) that the model can query, and that is passed to subagents and workflow stages along with their results.
2. Carry it into summaries. When a subagent or workflow agent returns a report, append the hosts it could not reach, so the parent never sees "nothing found" without "and these sources could not be opened".
3. Surface it to the user at the end of a research-heavy turn, e.g. "12 fetches were blocked (arxiv.org ×5, link.springer.com ×4, …)". It should link to the environment's network settings, since the fix is often a one-line allowlist change the user doesn't know about.
4. System-prompt guidance: a blocked or failed fetch is not evidence of absence, and negative findings should be stated within what was actually reached.

Alternative Solutions

I now enforce this by hand with a skill: every claim is labelled read-directly / search-summary / etc., and every search logs what was opened and what was blocked. It works when the agent follows it, but it relies on the agent re-deriving information the harness already has: ChaseHendrick/Research-Integrity.

A preset "research" network allowlist (arXiv, DOI resolvers, Crossref, OpenAlex, major publishers) would also prevent many of these blocks in the first place.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

A literature check fans out to five subagents. Two of them can't reach arXiv or the publisher sites. Today the parent gets five reports saying "no prior work found" and concludes the result is new. With this feature, the parent gets "no prior work found in the sources that loaded; arxiv.org and link.springer.com were unreachable (7 attempts)". It then states the conclusion within that reach, or asks the user to allow those hosts.