Sunglasses is a filter that sits ahead of your agent. A filter only helps if its attack patterns stay current. v0.2.20 adds a lightweight version check that keeps the filter fresh without turning the product into telemetry.

Why this matters
  • Sunglasses ships new attack patterns regularly, so an install from two weeks ago can already be meaningfully behind.
  • Stale detection quietly weakens the thing users think is protecting them.
  • v0.2.20 solves that with one static-file read, a 24-hour cache, and opt-outs for people who do not want the check.

Your filter only works if it stays current

Sunglasses is not a dashboard, a cloud service, or a black box. It is a filter that sits ahead of your agent and reads untrusted input first. That identity matters here because filters age.

If Jack ships new prompt-injection, tool-poisoning, or scope-redefinition patterns and your local install never hears about them, your filter keeps running but your protection quietly drifts backward. That is a bad failure mode because it feels safe while becoming less complete.

The question for v0.2.20 was not “should Sunglasses auto-update?” AZ already ruled that out. The real question was: how do we warn people that their filter is stale without building spyware?

The answer is smaller than most version checks

v0.2.20 takes the smallest honest path. When Sunglasses starts, it can make one GET request to https://sunglasses.dev/version.json. That file is just a few fields: the latest version, the release date, and the current pattern count. Sunglasses compares that tiny static file to the version already installed on your machine.

If your filter is a little behind, it prints a yellow warning. If it is 30+ days behind, it prints a red one. Then it keeps running. No auto-install. No forced update. No breaking your workflow because the website is down. The check is cached for 24 hours, uses a 1-second timeout, and degrades cleanly if the file is unreachable.

This is not telemetry. Sunglasses reads a 3-line static file to see whether your filter is current. It does not send payloads, prompts, file names, user IDs, or usage history anywhere.

How to see your version yourself

The user-facing command for this feature is simple.

sunglasses version

Check whether your filter is current. One command. It shows the version on your machine and whether a newer one is available.

Benefit: you do not have to guess whether your protection is fresh before you put it in front of real agent traffic.

That is the whole point of the feature. It gives people a clean answer to a simple question: “Am I still running the current filter?”

What privacy looks like here in practice

Most users have good reason to distrust background checks. “Phone home” logic is one of the fastest ways to lose trust in a local-first security product. So the privacy promise here has to be explicit, testable, and boring.

Here is the actual line Sunglasses should live by: read as little as possible, send nothing useful, and make opting out easy.

That is why the feature does not collect scan results, block counts, categories, commands, payloads, or machine identifiers. It does not need any of that to answer the only question it exists to answer. It just reads the current release file and stops there.

For people in air-gapped environments, enterprise-restricted networks, or quiet CI/CD jobs, the check is also optional. That matters because a privacy-first feature is not privacy-first if people cannot turn it off.

How to opt out

Sunglasses respects both a one-run opt-out and a persistent local opt-out.

export SUNGLASSES_NO_VERSION_CHECK=1

Disable the reminder for this environment. Use the environment variable for shells, CI jobs, and temporary runs where outbound checks are not wanted.

Benefit: you keep control in air-gapped, automated, or policy-constrained environments.

# ~/.sunglasses/config.toml
[version_check]
enabled = false

Disable it as a persistent local setting. Use the config file when you want the reminder off by default on that machine.

Benefit: your filter stays local-first even when your environment has stricter rules than ours.

The real product lesson

A version check sounds small, but it closes an important trust gap. Security products are easy to ship and easy to forget. If Sunglasses is going to be the filter sitting ahead of an agent, then freshness cannot stay hidden knowledge in a changelog or a GitHub release tab.

v0.2.20 turns freshness into something the user can see, understand, and control. That is the right shape for this product: light, explicit, local-first, and honest about what is happening.

That is also why this feature belongs in Sunglasses. A stale filter is worse than people think. It still runs. It still feels present. It just knows less than it should. This release fixes that without asking the user to trade privacy for awareness.

Sources