fix(desktop,runtime-host): omit WebSearch from tool surface when unavailable

[cat0825]

Summary

• omit WebSearch from the effective model tool surface when WebSearch is disabled, unconfigured, or privacy/incognito mode is active
• refresh idle Desktop backends when webSearch or privacy settings change
• preserve call-time fail-closed guards and deep-research allowlist behavior

Verification

• npm --workspace @maka/desktop run build:main
• npm --workspace @maka/runtime-host run build
• Desktop scoped tests: 25/25 passed
• Runtime Host web-search-tool.test.js: 3/3 passed
• Runtime Host execution-model-composition.test.js: 19/19 passed
• npx biome check <11 touched files>
• git diff --check

Closes#2085

[Astro-Han]

Thanks for picking this up — this PR identifies and addresses two real gaps that remain important: hiding Tavily-backed WebSearch when credentials are unavailable, and refreshing cached Desktop backends when web-search/privacy settings change.

I think we should hold this PR until #2152 lands, though. #2152 changes the authoritative WebSearch routing model by introducing provider-native search alongside Tavily. Rebasing this implementation as-is would create both textual conflicts and a semantic conflict: the current boolean availability check requires Tavily readiness, which would also hide valid provider-native WebSearch paths that do not need a Tavily key.

Once #2152 is merged, could you please rebase and reshape this into a narrower follow-up on top of its routeWebSearchTools seam?

The intended rules would be:

• disabled or privacy/incognito mode → hide WebSearch;
• defaultProvider: model → use the selected connection/model capability, without requiring Tavily credentials;
• defaultProvider: tavily → expose the tool only when the Tavily credential is actually usable.

I would keep the Desktop backend refresh work from this PR, but fold credential readiness into the unified router rather than retaining separate Desktop/Host boolean filters. It would also be valuable to add one lifecycle-level test showing that an existing idle backend’s effective tool surface changes after a settings update.

One small edge case to cover during the rebase: a whitespace-only saved Tavily key currently passes the surface check but is rejected after trimming at execution time.

So my recommendation is to wait for #2152, then rebase and preserve the useful incremental pieces here. This should reduce the conflict surface and leave WebSearch with one authoritative routing path.

[jackwener]

Closing per maintainer decision.

[cat0825]

Summary

• omit WebSearch from the effective model tool surface when WebSearch is disabled, unconfigured, or privacy/incognito mode is active
• refresh idle Desktop backends when webSearch or privacy settings change
• preserve call-time fail-closed guards and deep-research allowlist behavior

Verification

• npm --workspace @maka/desktop run build:main
• npm --workspace @maka/runtime-host run build
• Desktop scoped tests: 25/25 passed
• Runtime Host web-search-tool.test.js: 3/3 passed
• Runtime Host execution-model-composition.test.js: 19/19 passed
• npx biome check <11 touched files>
• git diff --check

Closes#2085

[Astro-Han]

Thanks for picking this up — this PR identifies and addresses two real gaps that remain important: hiding Tavily-backed WebSearch when credentials are unavailable, and refreshing cached Desktop backends when web-search/privacy settings change.

I think we should hold this PR until #2152 lands, though. #2152 changes the authoritative WebSearch routing model by introducing provider-native search alongside Tavily. Rebasing this implementation as-is would create both textual conflicts and a semantic conflict: the current boolean availability check requires Tavily readiness, which would also hide valid provider-native WebSearch paths that do not need a Tavily key.

Once #2152 is merged, could you please rebase and reshape this into a narrower follow-up on top of its routeWebSearchTools seam?

The intended rules would be:

• disabled or privacy/incognito mode → hide WebSearch;
• defaultProvider: model → use the selected connection/model capability, without requiring Tavily credentials;
• defaultProvider: tavily → expose the tool only when the Tavily credential is actually usable.

I would keep the Desktop backend refresh work from this PR, but fold credential readiness into the unified router rather than retaining separate Desktop/Host boolean filters. It would also be valuable to add one lifecycle-level test showing that an existing idle backend’s effective tool surface changes after a settings update.

One small edge case to cover during the rebase: a whitespace-only saved Tavily key currently passes the surface check but is rejected after trimming at execution time.

So my recommendation is to wait for #2152, then rebase and preserve the useful incremental pieces here. This should reduce the conflict surface and leave WebSearch with one authoritative routing path.

[jackwener]

Closing per maintainer decision.

[cat0825]

Summary

• omit WebSearch from the effective model tool surface when WebSearch is disabled, unconfigured, or privacy/incognito mode is active
• refresh idle Desktop backends when webSearch or privacy settings change
• preserve call-time fail-closed guards and deep-research allowlist behavior

Verification

• npm --workspace @maka/desktop run build:main
• npm --workspace @maka/runtime-host run build
• Desktop scoped tests: 25/25 passed
• Runtime Host web-search-tool.test.js: 3/3 passed
• Runtime Host execution-model-composition.test.js: 19/19 passed
• npx biome check <11 touched files>
• git diff --check

Closes#2085

[Astro-Han]

Thanks for picking this up — this PR identifies and addresses two real gaps that remain important: hiding Tavily-backed WebSearch when credentials are unavailable, and refreshing cached Desktop backends when web-search/privacy settings change.

I think we should hold this PR until #2152 lands, though. #2152 changes the authoritative WebSearch routing model by introducing provider-native search alongside Tavily. Rebasing this implementation as-is would create both textual conflicts and a semantic conflict: the current boolean availability check requires Tavily readiness, which would also hide valid provider-native WebSearch paths that do not need a Tavily key.

Once #2152 is merged, could you please rebase and reshape this into a narrower follow-up on top of its routeWebSearchTools seam?

The intended rules would be:

• disabled or privacy/incognito mode → hide WebSearch;
• defaultProvider: model → use the selected connection/model capability, without requiring Tavily credentials;
• defaultProvider: tavily → expose the tool only when the Tavily credential is actually usable.

I would keep the Desktop backend refresh work from this PR, but fold credential readiness into the unified router rather than retaining separate Desktop/Host boolean filters. It would also be valuable to add one lifecycle-level test showing that an existing idle backend’s effective tool surface changes after a settings update.

One small edge case to cover during the rebase: a whitespace-only saved Tavily key currently passes the surface check but is rejected after trimming at execution time.

So my recommendation is to wait for #2152, then rebase and preserve the useful incremental pieces here. This should reduce the conflict surface and leave WebSearch with one authoritative routing path.

[jackwener]

Closing per maintainer decision.

[cat0825]

Summary

• omit WebSearch from the effective model tool surface when WebSearch is disabled, unconfigured, or privacy/incognito mode is active
• refresh idle Desktop backends when webSearch or privacy settings change
• preserve call-time fail-closed guards and deep-research allowlist behavior

Verification

• npm --workspace @maka/desktop run build:main
• npm --workspace @maka/runtime-host run build
• Desktop scoped tests: 25/25 passed
• Runtime Host web-search-tool.test.js: 3/3 passed
• Runtime Host execution-model-composition.test.js: 19/19 passed
• npx biome check <11 touched files>
• git diff --check

Closes#2085

[Astro-Han]

Thanks for picking this up — this PR identifies and addresses two real gaps that remain important: hiding Tavily-backed WebSearch when credentials are unavailable, and refreshing cached Desktop backends when web-search/privacy settings change.

I think we should hold this PR until #2152 lands, though. #2152 changes the authoritative WebSearch routing model by introducing provider-native search alongside Tavily. Rebasing this implementation as-is would create both textual conflicts and a semantic conflict: the current boolean availability check requires Tavily readiness, which would also hide valid provider-native WebSearch paths that do not need a Tavily key.

Once #2152 is merged, could you please rebase and reshape this into a narrower follow-up on top of its routeWebSearchTools seam?

The intended rules would be:

• disabled or privacy/incognito mode → hide WebSearch;
• defaultProvider: model → use the selected connection/model capability, without requiring Tavily credentials;
• defaultProvider: tavily → expose the tool only when the Tavily credential is actually usable.

I would keep the Desktop backend refresh work from this PR, but fold credential readiness into the unified router rather than retaining separate Desktop/Host boolean filters. It would also be valuable to add one lifecycle-level test showing that an existing idle backend’s effective tool surface changes after a settings update.

One small edge case to cover during the rebase: a whitespace-only saved Tavily key currently passes the surface check but is rejected after trimming at execution time.

So my recommendation is to wait for #2152, then rebase and preserve the useful incremental pieces here. This should reduce the conflict surface and leave WebSearch with one authoritative routing path.

[jackwener]

Closing per maintainer decision.

[cat0825]

Summary

• omit WebSearch from the effective model tool surface when WebSearch is disabled, unconfigured, or privacy/incognito mode is active
• refresh idle Desktop backends when webSearch or privacy settings change
• preserve call-time fail-closed guards and deep-research allowlist behavior

Verification

• npm --workspace @maka/desktop run build:main
• npm --workspace @maka/runtime-host run build
• Desktop scoped tests: 25/25 passed
• Runtime Host web-search-tool.test.js: 3/3 passed
• Runtime Host execution-model-composition.test.js: 19/19 passed
• npx biome check <11 touched files>
• git diff --check

Closes#2085

[Astro-Han]

Thanks for picking this up — this PR identifies and addresses two real gaps that remain important: hiding Tavily-backed WebSearch when credentials are unavailable, and refreshing cached Desktop backends when web-search/privacy settings change.

I think we should hold this PR until #2152 lands, though. #2152 changes the authoritative WebSearch routing model by introducing provider-native search alongside Tavily. Rebasing this implementation as-is would create both textual conflicts and a semantic conflict: the current boolean availability check requires Tavily readiness, which would also hide valid provider-native WebSearch paths that do not need a Tavily key.

Once #2152 is merged, could you please rebase and reshape this into a narrower follow-up on top of its routeWebSearchTools seam?

The intended rules would be:

• disabled or privacy/incognito mode → hide WebSearch;
• defaultProvider: model → use the selected connection/model capability, without requiring Tavily credentials;
• defaultProvider: tavily → expose the tool only when the Tavily credential is actually usable.

I would keep the Desktop backend refresh work from this PR, but fold credential readiness into the unified router rather than retaining separate Desktop/Host boolean filters. It would also be valuable to add one lifecycle-level test showing that an existing idle backend’s effective tool surface changes after a settings update.

One small edge case to cover during the rebase: a whitespace-only saved Tavily key currently passes the surface check but is rejected after trimming at execution time.

So my recommendation is to wait for #2152, then rebase and preserve the useful incremental pieces here. This should reduce the conflict surface and leave WebSearch with one authoritative routing path.

[jackwener]

Closing per maintainer decision.

[cat0825]

Summary

• omit WebSearch from the effective model tool surface when WebSearch is disabled, unconfigured, or privacy/incognito mode is active
• refresh idle Desktop backends when webSearch or privacy settings change
• preserve call-time fail-closed guards and deep-research allowlist behavior

Verification

• npm --workspace @maka/desktop run build:main
• npm --workspace @maka/runtime-host run build
• Desktop scoped tests: 25/25 passed
• Runtime Host web-search-tool.test.js: 3/3 passed
• Runtime Host execution-model-composition.test.js: 19/19 passed
• npx biome check <11 touched files>
• git diff --check

Closes#2085

[Astro-Han]

Thanks for picking this up — this PR identifies and addresses two real gaps that remain important: hiding Tavily-backed WebSearch when credentials are unavailable, and refreshing cached Desktop backends when web-search/privacy settings change.

I think we should hold this PR until #2152 lands, though. #2152 changes the authoritative WebSearch routing model by introducing provider-native search alongside Tavily. Rebasing this implementation as-is would create both textual conflicts and a semantic conflict: the current boolean availability check requires Tavily readiness, which would also hide valid provider-native WebSearch paths that do not need a Tavily key.

Once #2152 is merged, could you please rebase and reshape this into a narrower follow-up on top of its routeWebSearchTools seam?

The intended rules would be:

• disabled or privacy/incognito mode → hide WebSearch;
• defaultProvider: model → use the selected connection/model capability, without requiring Tavily credentials;
• defaultProvider: tavily → expose the tool only when the Tavily credential is actually usable.

I would keep the Desktop backend refresh work from this PR, but fold credential readiness into the unified router rather than retaining separate Desktop/Host boolean filters. It would also be valuable to add one lifecycle-level test showing that an existing idle backend’s effective tool surface changes after a settings update.

One small edge case to cover during the rebase: a whitespace-only saved Tavily key currently passes the surface check but is rejected after trimming at execution time.

So my recommendation is to wait for #2152, then rebase and preserve the useful incremental pieces here. This should reduce the conflict surface and leave WebSearch with one authoritative routing path.

[jackwener]

Closing per maintainer decision.

[cat0825]

Summary

• omit WebSearch from the effective model tool surface when WebSearch is disabled, unconfigured, or privacy/incognito mode is active
• refresh idle Desktop backends when webSearch or privacy settings change
• preserve call-time fail-closed guards and deep-research allowlist behavior

Verification

• npm --workspace @maka/desktop run build:main
• npm --workspace @maka/runtime-host run build
• Desktop scoped tests: 25/25 passed
• Runtime Host web-search-tool.test.js: 3/3 passed
• Runtime Host execution-model-composition.test.js: 19/19 passed
• npx biome check <11 touched files>
• git diff --check

Closes#2085

[Astro-Han]

Thanks for picking this up — this PR identifies and addresses two real gaps that remain important: hiding Tavily-backed WebSearch when credentials are unavailable, and refreshing cached Desktop backends when web-search/privacy settings change.

I think we should hold this PR until #2152 lands, though. #2152 changes the authoritative WebSearch routing model by introducing provider-native search alongside Tavily. Rebasing this implementation as-is would create both textual conflicts and a semantic conflict: the current boolean availability check requires Tavily readiness, which would also hide valid provider-native WebSearch paths that do not need a Tavily key.

Once #2152 is merged, could you please rebase and reshape this into a narrower follow-up on top of its routeWebSearchTools seam?

The intended rules would be:

• disabled or privacy/incognito mode → hide WebSearch;
• defaultProvider: model → use the selected connection/model capability, without requiring Tavily credentials;
• defaultProvider: tavily → expose the tool only when the Tavily credential is actually usable.

I would keep the Desktop backend refresh work from this PR, but fold credential readiness into the unified router rather than retaining separate Desktop/Host boolean filters. It would also be valuable to add one lifecycle-level test showing that an existing idle backend’s effective tool surface changes after a settings update.

One small edge case to cover during the rebase: a whitespace-only saved Tavily key currently passes the surface check but is rejected after trimming at execution time.

So my recommendation is to wait for #2152, then rebase and preserve the useful incremental pieces here. This should reduce the conflict surface and leave WebSearch with one authoritative routing path.

[jackwener]

Closing per maintainer decision.

[cat0825]

Summary

• omit WebSearch from the effective model tool surface when WebSearch is disabled, unconfigured, or privacy/incognito mode is active
• refresh idle Desktop backends when webSearch or privacy settings change
• preserve call-time fail-closed guards and deep-research allowlist behavior

Verification

• npm --workspace @maka/desktop run build:main
• npm --workspace @maka/runtime-host run build
• Desktop scoped tests: 25/25 passed
• Runtime Host web-search-tool.test.js: 3/3 passed
• Runtime Host execution-model-composition.test.js: 19/19 passed
• npx biome check <11 touched files>
• git diff --check

Closes#2085

[Astro-Han]

Thanks for picking this up — this PR identifies and addresses two real gaps that remain important: hiding Tavily-backed WebSearch when credentials are unavailable, and refreshing cached Desktop backends when web-search/privacy settings change.

I think we should hold this PR until #2152 lands, though. #2152 changes the authoritative WebSearch routing model by introducing provider-native search alongside Tavily. Rebasing this implementation as-is would create both textual conflicts and a semantic conflict: the current boolean availability check requires Tavily readiness, which would also hide valid provider-native WebSearch paths that do not need a Tavily key.

Once #2152 is merged, could you please rebase and reshape this into a narrower follow-up on top of its routeWebSearchTools seam?

The intended rules would be:

• disabled or privacy/incognito mode → hide WebSearch;
• defaultProvider: model → use the selected connection/model capability, without requiring Tavily credentials;
• defaultProvider: tavily → expose the tool only when the Tavily credential is actually usable.

I would keep the Desktop backend refresh work from this PR, but fold credential readiness into the unified router rather than retaining separate Desktop/Host boolean filters. It would also be valuable to add one lifecycle-level test showing that an existing idle backend’s effective tool surface changes after a settings update.

One small edge case to cover during the rebase: a whitespace-only saved Tavily key currently passes the surface check but is rejected after trimming at execution time.

So my recommendation is to wait for #2152, then rebase and preserve the useful incremental pieces here. This should reduce the conflict surface and leave WebSearch with one authoritative routing path.

[jackwener]

Closing per maintainer decision.