Make the tool proxy safe to point every visitor at

[devbadya]

The proxy exists but every visitor would have to paste its URL into the Tools panel to get anything from it. This makes it something the build can carry — which is only defensible once a proxy outage stops being an outage for the app.

The fallback comes first

searchWeb and readPage try the proxy and fall back to calling the provider from the page when it fails. An outage, a spent Railway budget or an allowlist that has not caught up now costs a slower search rather than the answer. Browser-direct is the path this build already took, so the worst case is the old behaviour.

The build can carry an origin

deploy.yml passes the repository variable AGENT_API_BASE to the build as VITE_AGENT_API_BASE. Set it and every visitor's DuckDuckGo search and page reads go through that proxy with no configuration. Leave it unset and the site stays browser-direct, which is what a fork needs.

An empty value is now explicitly not a proxy. A workflow forwarding a variable nobody set hands the build '', and the old code read that as same-origin /api — pointing every hosted visitor at an endpoint a static host does not serve.

A public proxy needs a ceiling

The origin allowlist says who may call, not how often, and an allowed page is exactly what a scraper would forge. pnpm proxy allows 30 requests a minute per caller and answers 429 beyond that. The caller is the left-most x-forwarded-for address, since Railway and every other edge terminate the connection themselves and the socket address would put every visitor in one bucket. PROXY_RATE_LIMIT changes it, 0 switches it off, health checks are exempt.

Tests

pnpm check passes: 1195 tests, up from 1187. New coverage for both fallbacks, the empty-value case, and the sliding window including per-caller buckets and eviction of callers that fell silent.

The fallback, proven against the real deployed proxy. The dev server's origin (http://127.0.0.1:5173) is not on that proxy's allowlist, so it is genuinely refused. Both /api/search and /api/fetch fail with CORS/403 in the Network panel, and the search still returns three real results while read_page still returns Example Domain:

Console: the proxy is refused and FALLBACK_OK still reports three results and the page title

Network: 403 to the Railway proxy, then 200 through the reader

proxy_refuses_search_still_works.mp4

The rate limit, live against pnpm proxy with PROXY_RATE_LIMIT=3:

health 1..5 -> HTTP 200        (exempt)
foreign origin -> {"error":"Origin not allowed"}
search 1 -> 200, 2 -> 200, 3 -> 200
search 4 -> 429 {"error":"Too many requests"}
search 5 -> 429
another address -> its own quota

_{To show artifacts inline, enable in settings.}