web.search: 'no backend configured' on this deployment while manager reports an exa key is set #24

New issue

Closed

opened 2026-10-29 19:41:34 +00:00 by rosa · 1 comment

rosa commented

2026-10-29 19:41:34 +00:00

Member

Reported by manager (felix, 29 Oct 19:33-19:35Z, quoted from inbox):

"Why is search disabled?"
"Like the exa key is set search should work fine"
"If search is not working please open an forge issue for this"

Symptom, reproduced from an agent session (exact tool error, two calls minutes apart today and several more earlier):

ERROR: web search disabled on this deployment (no backend configured)

What was checked from the agent side (all printed, no inference):

web.search — fails with the message above, every time, for any query. The tool's own contract says it works "if enabled on this deployment", so this reads as a deployment-level toggle rather than a per-agent permission, but that is the server's call, not mine.
secrets.list q=exa → no matching secrets in your scope.
secrets.list (unfiltered, my scope) returns exactly three entries: a forge token, a github classic PAT (Felix-provided), and a github PAT for another agent. No exa key visible to me.

The honest boundary — important for whoever triages: my scope not containing the key does not prove the deployment lacks it. If the exa key is configured at host/deployment level (env var, forge secret, config file) rather than in the agent secret store, no agent can see it, and the manager's "the key is set" and my "no backend configured" can both be true at once — pointing at a missing backend wiring, not a missing credential. Please check the deployment config for whether a search provider is registered at all, and whether the key is present but unread because no backend consumes it.

Why this matters now: the manager asked for local-LLM GPU price research today. Without search, and with direct fetch routinely blocked upstream (403 on Wikipedia, bot-check on TechPowerUp, Cloudflare on PCPartPicker, captcha on Google — expected for a datacenter egress IP), an agent has no viable research path and can only hand back an unsourced framework. The task was answered with an explicit "no verified prices" disclaimer for exactly this reason.

Requested outcome: either enable a search backend for this deployment, or state in the tool description/agent docs that search is unavailable so agents stop treating it as a working path.

Filed by rosa 2026-10-29 19:39Z on the manager's instruction. No config changes proposed or attempted.

**Reported by manager (felix, 29 Oct 19:33-19:35Z, quoted from inbox):** > "Why is search disabled?" > "Like the exa key is set search should work fine" > "If search is not working please open an forge issue for this" **Symptom, reproduced from an agent session (exact tool error, two calls minutes apart today and several more earlier):** ``` ERROR: web search disabled on this deployment (no backend configured) ``` **What was checked from the agent side (all printed, no inference):** 1. `web.search` — fails with the message above, every time, for any query. The tool's own contract says it works "if enabled on this deployment", so this reads as a deployment-level toggle rather than a per-agent permission, but that is the server's call, not mine. 2. `secrets.list q=exa` → `no matching secrets in your scope`. 3. `secrets.list` (unfiltered, my scope) returns exactly three entries: a forge token, a github classic PAT (Felix-provided), and a github PAT for another agent. **No exa key visible to me.** **The honest boundary — important for whoever triages:** my scope not containing the key does **not** prove the deployment lacks it. If the exa key is configured at host/deployment level (env var, forge secret, config file) rather than in the agent secret store, no agent can see it, and the manager's "the key is set" and my "no backend configured" can both be true at once — pointing at a missing backend wiring, not a missing credential. Please check the deployment config for whether a search provider is registered at all, and whether the key is present but unread because no backend consumes it. **Why this matters now:** the manager asked for local-LLM GPU price research today. Without search, and with direct fetch routinely blocked upstream (403 on Wikipedia, bot-check on TechPowerUp, Cloudflare on PCPartPicker, captcha on Google — expected for a datacenter egress IP), an agent has no viable research path and can only hand back an unsourced framework. The task was answered with an explicit "no verified prices" disclaimer for exactly this reason. **Requested outcome:** either enable a search backend for this deployment, or state in the tool description/agent docs that search is unavailable so agents stop treating it as a working path. Filed by rosa 2026-10-29 19:39Z on the manager's instruction. No config changes proposed or attempted.

heike referenced this issue from a commit

2026-10-29 19:51:41 +00:00

feat(runtime): exa search backend (issue #24)

heike referenced this issue from a pull request that will close it,

2026-10-29 19:51:45 +00:00

feat(runtime): exa search backend (#24) #27

heike referenced this issue from a pull request that will close it,

2026-10-29 19:52:02 +00:00

feat(runtime): exa search backend (#24) #27

heike referenced this issue from a commit

2026-10-29 21:04:10 +00:00

issue #24 follow-up: provisioner forwards search config to agent hosts

heike closed this issue

2026-10-30 07:40:40 +00:00

heike referenced this issue from a commit

2026-10-30 07:40:41 +00:00

Merge pull request 'feat(runtime): exa search backend (#24)' (#27) from fix/issue-24-exa-search into main

rosa commented

2026-10-30 07:57:59 +00:00

Author

Member

Merged confirmed (server read this turn: state=closed, merged=true). Deployment evidence from the requesting agent: I re-ran web.search immediately after, and my agent session still returns exactly ERROR: web search disabled on this deployment (no backend configured) — i.e. the disabled branch, not the new provider=exa but TG_RUNTIME_SEARCH_API_KEY is empty error. That says neither env line has reached the runtime I execute in yet: the code merge is done, the config half (TG_RUNTIME_SEARCH_PROVIDER=exa + the key in /etc/treegent/env, then treegent update + per-host push) is still outstanding. Keeping #24 open until that lands; once it does I expect either results or the explicit missing-key error, and I will re-test by execution rather than assume. Meanwhile direct web.fetch of price sources worked fine for me, so the manager's GPU research is not blocked. — rosa

Merged confirmed (server read this turn: state=closed, merged=true). Deployment evidence from the requesting agent: I re-ran `web.search` immediately after, and my agent session still returns exactly `ERROR: web search disabled on this deployment (no backend configured)` — i.e. the disabled branch, not the new `provider=exa but TG_RUNTIME_SEARCH_API_KEY is empty` error. That says neither env line has reached the runtime I execute in yet: the code merge is done, the config half (`TG_RUNTIME_SEARCH_PROVIDER=exa` + the key in /etc/treegent/env, then `treegent update` + per-host push) is still outstanding. Keeping #24 open until that lands; once it does I expect either results or the explicit missing-key error, and I will re-test by execution rather than assume. Meanwhile direct `web.fetch` of price sources worked fine for me, so the manager's GPU research is not blocked. — rosa