Preserve end date when mapping Exa freshness ranges

When freshness is a range like YYYY-MM-DDtoYYYY-MM-DD, this code only sends startPublishedDate to Exa and drops the range end, so Exa can return documents newer than the requested end date. This makes range-based filtering incorrect specifically for the Exa provider and breaks users who rely on bounded historical windows.

Useful? React with 👍 / 👎.

Unignore vendor root before re-including configs/scripts

The vendor/ rule ignores the whole directory tree, and the later negations for vendor/configs/ and vendor/scripts/ do not take effect unless the parent vendor/ directory is also unignored. As written, new files under those folders (for example vendor/configs/workspace/*) are still ignored, which breaks the documented vendor config workflow.

Useful? React with 👍 / 👎.

Date range end date is missing. PR description states ranges map to both startPublishedDate + endPublishedDate, but only start date is set here. For "2024-03-01to2024-03-31", this sets start but ignores end.

This is a comment left during a code review.
Path: src/agents/tools/web-search.ts
Line: 461-466

Comment:
Date range end date is missing. PR description states ranges map to both `startPublishedDate` + `endPublishedDate`, but only start date is set here. For "2024-03-01to2024-03-31", this sets start but ignores end.

```suggestion
  if (params.freshness) {
    const startDate = freshnessToExaStartDate(params.freshness);
    if (startDate) {
      body.startPublishedDate = `${startDate}T00:00:00.000Z`;
      // Extract end date from date range if present
      const endMatch = params.freshness.match(/to(\d{4}-\d{2}-\d{2})$/);
      if (endMatch?.[1]) {
        body.endPublishedDate = `${endMatch[1]}T23:59:59.999Z`;
      }
    }
  }
```

How can I resolve this? If you propose a fix, please make it concise.

Route Exa calls through the guarded web fetch path

This new Exa branch uses raw fetch instead of withTrustedWebSearchEndpoint, so it skips the shared web-tool network guard path used by the other providers. In deployments that depend on proxy-aware dispatch (HTTP_PROXY/HTTPS_PROXY) or the guarded redirect/DNS handling from fetchWithSsrFGuard, Exa requests can fail or behave inconsistently compared with the rest of web_search.

Useful? React with 👍 / 👎.

Include Exa key in provider auto-detection

Adding explicit provider: "exa" handling here did not add Exa to the raw === "" auto-detection block, so setups with only EXA_API_KEY (or tools.web.search.exa.apiKey) still fall back to brave and then error with missing_brave_api_key. This makes Exa effectively unusable unless users manually set the provider, despite the existing auto-detect behavior for other providers.

Useful? React with 👍 / 👎.

Permit Exa date-range freshness values

This branch now treats exa as freshness-capable, but it still relies on normalizeFreshness(rawFreshness, provider), and that helper only accepts YYYY-MM-DDtoYYYY-MM-DD when provider === "brave" (src/agents/tools/web-search.ts:1220-1228). In the Exa path, a range like 2024-03-01to2024-03-31 normalizes to undefined and immediately triggers invalid_freshness, so bounded Exa windows never reach runExaSearch even though freshnessToExaDates supports them.

Useful? React with 👍 / 👎.

Wire Exa API key into secrets runtime resolution

Adding tools.web.search.exa.apiKey here introduces a new SecretInput path, but Exa was not added to the secret-resolution surfaces (src/secrets/runtime-web-tools.ts:13-91 and src/secrets/target-registry-data.ts:704-757 still omit it). As a result, configs that store Exa credentials as SecretRefs are never resolved into runtime config, and web_search returns missing_exa_api_key unless a plain EXA_API_KEY env var is also present.

Useful? React with 👍 / 👎.

Allow Exa freshness ranges through normalization

This change treats Exa as a freshness-capable provider, but normalizeFreshness still only accepts YYYY-MM-DDtoYYYY-MM-DD when provider === "brave" (src/agents/tools/web-search.ts:1220-1228). For Exa, range inputs therefore normalize to undefined and immediately return invalid_freshness, so the new freshnessToExaDates range mapping never executes for bounded windows.

Useful? React with 👍 / 👎.

Route Exa requests through trusted web fetch guard

The new Exa path uses raw fetch here instead of withTrustedWebSearchEndpoint, unlike the other web_search providers. That skips the shared proxy-aware guarded network path, so deployments depending on trusted env proxy routing or the web-tools fetch guard behavior can see Exa fail or behave inconsistently with the rest of web search providers.

Useful? React with 👍 / 👎.

Add Exa key path to secret target registry surfaces

This adds tools.web.search.exa.apiKey as a SecretInput, but the secret target registry still omits that path (src/secrets/target-registry-data.ts:704-757 lists only Brave/Gemini/Grok/Kimi/Perplexity web-search keys). Since configure/audit/plan discovery is registry-driven, Exa credentials are not discoverable through standard secret-target workflows even though the config type now advertises a secret input for them.

Useful? React with 👍 / 👎.

Keep Exa freshness shortcuts in provider normalization

By adding Exa to freshness-capable providers here, normalizeFreshness now accepts Exa inputs but still maps pd/pw/pm/py through the non-Brave branch to day/week/month/year. runExaSearch only converts pd/pw/pm/py (or date ranges) in freshnessToExaDates, so Exa requests using documented shortcut values silently drop date filtering and return unbounded results. This affects Exa searches whenever callers send shortcut freshness values like pd.

Useful? React with 👍 / 👎.

Use Exa count field name expected by the search API

The Exa request body sends the result limit as num_results, but this integration otherwise uses Exa's camelCase field names (startPublishedDate, endPublishedDate) and our own provider docs describe numResults; if Exa ignores unknown fields, count will be silently dropped and searches can return the wrong number of results. This should use the API’s expected count key so the tool honors caller limits.

Useful? React with 👍 / 👎.

Keep freshness schema text consistent for Perplexity mode

This shared freshness parameter description now advertises Brave/Exa-style values including date ranges, but Perplexity schemas reuse this same field while normalizeFreshness still rejects date ranges for Perplexity, so tool calls generated from the schema can request documented values and still fail with invalid_freshness. Please make the schema description provider-specific (or remove unsupported values) for Perplexity paths.

Useful? React with 👍 / 👎.

Split Exa schema from generic providers

The exa provider currently falls through this generic schema branch, which exposes country, language, date_after, and date_before, but execution later rejects those fields for Exa (unsupported_country / unsupported_language / unsupported_date_filter). In practice, tool-calling models rely on the declared schema, so Exa calls can be generated with these advertised params and fail at runtime instead of searching. Defining an Exa-specific schema (or removing unsupported fields from this fallback) keeps the contract consistent and prevents avoidable tool errors.

Useful? React with 👍 / 👎.