The refresh hint is derived from one value: the timestamp saying when the cloud account was last read. When that timestamp is null, the server treats it as "cannot vouch for this", and the hint goes true on every response from then on [12]. It fired correctly. It also stopped carrying information, because a hint that appears on almost every answer looks the same as a hint that is stuck [1].
An earlier version of the same problem had a cleaner shape. The cache entries expired on different clocks, the graph at twenty-four hours and the cloud metadata and the provenance record at one [9], while the warning threshold sat at six hours [2]. Subtract, and every long session had a five-hour band in which the companion entries were already null and the hint had said nothing yet [16]. The current bug moves that gap to the far side of the twenty-four hour mark. The file-save path rewrites three of the five entries and resets their clocks, leaves the other two alone, and reads no cloud API while it works [10] [17]. So a session where you keep editing holds the graph alive indefinitely while the metadata underneath it expires, and the rebuilt graph ends up with no cloud facts in it at all [11].
None of these paths raise. A missing analyzer returns a shorter findings array, and an empty findings array is what a healthy account looks like [14]. Expired metadata returns a graph with fewer nodes [15]. The degradation is toward the shape of good news, which is the shape nobody re-checks.
Two of the four documented failures never touch the read-time at all. The analyzer omission is one missing line in the second list, and one file save retires that category of finding for the rest of the session [7]. The boot snapshot bug served state that had a perfectly valid timestamp attached to it, so a fresh analysis in another terminal appeared to do nothing [8]. No signal computed from age can see either of those [18]. What separates a healthy session from a hollow one is a count: nodes in the graph, findings per analyzer, whether any cloud-derived fact is present [14] [15]. A check that would have caught all four has to compare what the incremental path produced against what a full run produces [13], which is a different question from how old the data is.
This is one repository, written up by the developer who shipped all four of the bugs in it [4]. Three things have to be true for the pattern to be yours. The context server holds state across tool calls instead of fetching per call [5]. Part of that state refreshes on a trigger you do not control, such as a file save [10]. And the state lives in more than one entry with independent lifetimes [9]. Break any one of those and this specific failure cannot happen. A server that re-reads the account on every tool call is immune, and pays for immunity with a cloud API call on every question the assistant asks [6].
